The Website Header Checklist Agencies Should Run on Every Client Site

An agency website security headers checklist should review HSTS, X-Content-Type-Options, X-Frame-Options or CSP frame-ancestors, Referrer-Policy, Permissions-Policy, and Content-Security-Policy presence. These are public header signals returned by the website, CDN, or application, and they are useful during client site reviews because they show whether common baseline header hygiene is being sent with the public response.

This tool checks public trust signals only. It is not a security audit, vulnerability scan, malware scan, or compliance check.

Use this checklist as a practical review layer, not as a deep application assessment. CertPilot's Client Website Trust Check checks header presence and key values for one public URL. For teams reviewing several client domains, the free agency audit can be used alongside header review to cover SSL, DNS, domain expiry, and email-authentication signals.

For the broader public trust-signal framework, use the client website trust signals guide.

Quick answer: the website header checklist

For most agency client websites, the first-pass header checklist is:

• Strict-Transport-Security
• X-Content-Type-Options: nosniff
• X-Frame-Options or Content-Security-Policy with frame-ancestors
• Referrer-Policy
• Permissions-Policy
• Content-Security-Policy

The presence of these headers is not a full quality judgment. Values matter, app behavior matters, and some policies need developer testing. The point of the checklist is to find missing public signals and route improvements to the right owner.

Why headers matter during client site reviews

Headers are often configured outside the page template. A designer may never see them. A CMS editor may not control them. A developer may assume the host or CDN adds them. A hosting provider may only add some defaults. Because ownership is split, headers are easy to miss during launch QA.

Agencies should include header review when:

• A new site is handed over.
• A CDN or host changes.
• A client moves from staging to production.
• A custom app launches behind a reverse proxy.
• A care-plan review needs practical proof items.
• A client asks whether public website basics were checked.

For methodology notes on public checks, data sources, and limitations, see the CertPilot methodology.

HSTS: HTTPS-only behavior

HSTS is sent with the Strict-Transport-Security header. It tells browsers to prefer HTTPS for the site for a specified period after a successful HTTPS visit. MDN's Strict-Transport-Security reference explains the directive and common parameters.

Agencies should check whether HSTS is present on the HTTPS response and whether the value is intentional. A typical review looks for max-age, and sometimes includeSubDomains or preload when the organization has confirmed that every subdomain is ready.

Do not enable broad HSTS settings casually on client domains with unknown subdomains. The right action may be to ask the host or developer for a staged rollout plan.

X-Content-Type-Options: nosniff

X-Content-Type-Options: nosniff is a simple baseline header signal. It tells browsers not to guess a different MIME type for certain resources. MDN documents the header in its X-Content-Type-Options reference.

For agency QA, this is usually a yes/no item. If it is missing, the recommended improvement is often straightforward: configure the web server, CDN, or framework middleware to send it on public responses.

X-Frame-Options or CSP frame-ancestors

Framing control can be declared through X-Frame-Options or through Content-Security-Policy using frame-ancestors. The goal is to state where the page may be embedded.

For a basic marketing site, the expected value may be restrictive. For embedded widgets, portals, or client dashboards, the correct configuration may be more nuanced. Agencies should avoid making a blanket recommendation without knowing whether the site is intentionally embedded elsewhere.

The practical checklist item is: does the public response send a framing signal, and does the value match the client use case?

Referrer-Policy

Referrer-Policy controls how much referrer information the browser sends when a visitor moves from one URL to another. MDN's Referrer-Policy reference covers the available values.

Agencies should look for an explicit policy rather than relying on defaults. Common values include strict-origin-when-cross-origin, same-origin, and no-referrer, depending on analytics, attribution, and application needs.

Permissions-Policy

Permissions-Policy lets a site declare which browser features are allowed by default, such as camera, microphone, geolocation, and related capabilities. MDN provides a Permissions-Policy reference.

For many client marketing sites, a simple restrictive baseline is appropriate. For apps that use browser features, the policy needs product-specific review. The trust check should report presence and obvious absence, not decide every feature choice.

CSP presence without overclaiming quality

Content-Security-Policy can be simple or complex. Presence alone is useful, but it does not prove policy quality. A policy may be too loose, too strict, broken for the page, or missing important directives. MDN's Content-Security-Policy reference is a useful starting point for developers.

For agency reporting, phrase CSP findings carefully:

• "CSP was not detected on the checked response."
• "CSP is present; deeper policy review may be needed."
• "frame-ancestors was detected in CSP."

That keeps the report factual and avoids overclaiming.

Common header mistakes agencies see

| Header | What to look for | Common missing signal | Recommended improvement | |---|---|---|---| | HSTS | Strict-Transport-Security on HTTPS | No HTTPS-only behavior signal | Ask host/CDN to add a tested HSTS policy | | X-Content-Type-Options | nosniff | Header absent | Add nosniff at server, CDN, or app layer | | Framing control | X-Frame-Options or CSP frame-ancestors | No framing signal | Add a framing rule that matches the site use case | | Referrer-Policy | Explicit referrer policy | Browser default only | Set an intentional policy | | Permissions-Policy | Intentional feature limits | Header absent | Limit browser features not used by the site | | CSP | Header present and tested | No CSP signal | Add a staged policy with developer testing |

Header findings are usually not copywriting tasks. They need the person who controls the host, CDN, reverse proxy, framework middleware, or server config.

What Client Website Trust Check reports

The Client Website Trust Check reports whether these public header signals are present on the checked URL. It also includes HTTPS/TLS, certificate expiry, redirect behavior, visible cookie flags, CAA, robots.txt, sitemap.xml, and security.txt.

The tool does not deeply score CSP quality or guarantee that every route sends the same headers. It checks the public URL submitted and reports what is visible in that response.

We make a small number of public requests to the domain you submit. We do not log in, scan plugins, or crawl the site.

Some signals are only visible if the site responds normally on the public URL being checked. Sites behind WAFs, geo-blocks, or aggressive bot protection may show unknown rather than missing.

When to hand this to a developer or hosting provider

Send header findings to the owner who can act:

• CDN owner for Cloudflare, Fastly, or similar edge configuration.
• Host for managed WordPress or managed platform defaults.
• Developer for framework middleware, reverse proxy config, or app headers.
• Client IT team for domain-wide policies.

Include the exact URL checked, the observed header, the missing signal, and the recommended improvement. Avoid asking for a vague "site hardening" task. Ask for the specific header and value to be reviewed.

Related Resources

• Client Website Trust Signals Checker
• Client website health report template
• Agent-friendly web page checklist
• Monitor DNS changes on client websites

Frequently Asked Questions

What is included in a website security headers checklist?

A website security headers checklist usually includes HSTS, X-Content-Type-Options, framing controls, Referrer-Policy, Permissions-Policy, and CSP presence. For agency reviews, the checklist should focus on public header signals and recommended improvements. Values still need site-specific review, especially when a client app embeds content, uses browser features, or has a complex CSP.

Should every client site use the same header values?

No. Many baseline headers are broadly useful, but exact values depend on the site. A brochure site, ecommerce store, embedded app, and client portal can have different needs. The agency should treat missing headers as review items, then confirm the correct values with the developer, host, or CDN owner.

Does CSP presence mean the policy is well designed?

No. CSP presence means the public response includes a policy signal. The policy may still be incomplete, overly broad, or incompatible with parts of the site. A first-pass trust check can report whether CSP exists, but deeper CSP review requires developer testing and route-by-route context.

Why does HSTS need care?

HSTS affects how browsers use HTTPS after a successful HTTPS visit. Broad settings such as includeSubDomains or preload can affect many hostnames. Agencies should confirm DNS, subdomains, and hosting coverage before asking for aggressive HSTS settings across a client domain.

Who usually fixes missing headers?

The owner depends on the stack. It may be the hosting provider, CDN manager, DevOps engineer, application developer, or managed platform support team. The most useful agency handoff is a short list of observed missing signals with the exact URL checked and a recommended improvement.

Can Client Website Trust Check replace manual review?

No. It is a passive public check. It can identify visible header signals and useful improvements, but it does not inspect every route, run JavaScript, authenticate, or evaluate full application behavior. Use it as a fast review layer before deeper technical QA when needed.