B2B services company, Europe.

What triggered it

A commercial block. A customer's corporate DNS filter was rejecting our client's domain, and a supplier whose website a customer's network refuses to resolve has a business problem, not an IT one.

The brief we were given was "our site looks hacked to them". It was not.

The diagnosis, in a week

We delivered a technical report on security, SSL and reputation, built on public reference scanners: SSL analysis, HTTP header scan, domain reputation, safe browsing and multi-engine antivirus. Anyone can re-run all of them, which is the point.

The conclusion was clear. The site was not compromised and it was not on any blacklist. This was a hardening and configuration problem, not an infection.

TLS was already in good shape before we started: valid certificate, TLS 1.3 active, no weak ciphers, valid chain, forward secrecy. SSL graded A at the initial diagnosis, before we touched anything. Three other things were driving the automatic "low security posture" classification that corporate filters act on:

• No HTTP security headers at all. Header grade: F.
• An expired, non-matching backup certificate exposed by the shared hosting.
• Visible server fingerprints: interpreter version, control panel signature and technology header.

The constraint that decided the architecture

The only access available was the CMS admin panel. No hosting access means server-level hardening is not applicable on the original infrastructure, so migrating was the only route.

The other option was rebuilding the site in code: an estimated three to six weeks, with the domain still blocked for all of them. The migration was reversible and unblocked sooner. The static rebuild stayed on the shelf as a deferred phase.

What changed, exactly

The work ran in three phases: migration with functional verification and a pass over URLs and permalinks, security and configuration hardening, and reputation cleanup.

Headers actually served after hardening

HSTS with includeSubdomains, a Content-Security-Policy, the legacy XSS protection header, nosniff, X-Frame-Options set to SAMEORIGIN, a strict Referrer-Policy, a Permissions-Policy with the full list of sensitive APIs disabled, and a server header with no version in it.

The CMS layer

Internal paths remapped, common paths and files hidden, the login path moved with a custodied emergency URL, brute force protection, an application firewall that blocks IPs automatically, XML-RPC disabled, discovery endpoints switched off and theme detectors blocked. AI crawlers were left allowed on purpose, because search visibility was part of the job.

What we claim and what we do not

We claim only what we did and measured. No CVE list or vulnerability count was recorded, so we publish no number of vulnerabilities closed.

The DNS cutover

TTL lowered 24 to 48 hours ahead, A record changed, and the mail records (MX, SPF, DKIM and DMARC) left untouched, so corporate mail on the domain never stopped.

How it was measured, and what that measurement is worth

Before: headers F, SSL A. After hardening: A+ on headers, from a scan forced without cache and returning no warnings.

That A+ was read on the migration host, in 2026, before the live domain was cut over. We have no record of a re-scan of the live domain after the cutover, so we do not present A+ as a production result.

This applies to any site. A header grade is a dated photograph of one host, not a property the site owns from then on. A new embed, a new plugin, a provider default and the grade moves. If you want to know what a site scores today, scan it today.

The link audit, and why it exists

After the DNS change we audited 24 pages, 12 in each language, link by link. That pass caught and fixed every reference to the staging environment the first automated replacement had left behind: in the global footer, in the page builder CTAs, in the consent links inside forms, in several PDFs, in legal texts and in a theme icon font.

The reusable lesson: a mass replacement can run in dry-run mode and be assumed done. A change is not done until a real request against the live site proves it.

Close, and what we do not claim

The project closed with a delivery report as a PDF, the technical work complete, a clean link audit and a 30-day technical warranty. Four days from award to technical close.

What we do not claim: lifting the DNS block is the customer's decision, and the reputation review requests filed at the end were still with the reviewers at close.

The method, in order

This order works for the next site too. Measure with public tools anyone can re-run. Fix the configuration rather than the story. Measure again, naming the host and the date of the scan. Then audit against the live site instead of against the plan.