HSTS Checklist for Agencies: What to Review on Client Websites

An HSTS checklist helps agencies review whether a client site sends a Strict-Transport-Security header and whether the visible values, such as max-age and includeSubDomains, look intentional for the site. The goal is not to make a broad promise about the whole application. The goal is to confirm that the public HTTPS response includes an HTTPS-only browser signal and to route questionable values to the developer, host, CDN owner, or client IT team.

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

For one public URL, use the Client Website Trust Check to review HSTS alongside HTTPS/TLS, redirect behavior, other header hygiene signals, cookie flags, CAA, and public metadata. For a wider portfolio conversation, pair that with the free 10-domain agency audit.

Quick answer: HSTS checklist for agencies

The practical HSTS checklist for agencies is:

• Confirm the site loads over HTTPS.
• Confirm HTTP requests redirect to HTTPS.
• Check whether Strict-Transport-Security appears on the HTTPS response.
• Review the max-age value.
• Check whether includeSubDomains is present.
• Check whether preload is present.
• Confirm broad settings are intentional before recommending changes.
• Document the URL checked, observed value, owner, and recommended improvement.

HSTS should be reviewed as header hygiene, not as a stand-alone proof item. A missing HSTS signal can be a useful recommendation, but it needs context from the hosting stack and subdomain inventory.

What HSTS does

HSTS stands for HTTP Strict Transport Security. It is sent through the Strict-Transport-Security response header. After a browser has successfully visited a site over HTTPS and received the header, the browser can remember that the site should be requested over HTTPS for the time period in max-age.

In plain language: HSTS tells the browser, "for this host, prefer HTTPS for a while." MDN's Strict-Transport-Security reference explains the directive and its common parameters.

For agency work, HSTS is most useful as a public website posture signal. It shows that the client site is not only reachable over HTTPS, but is also sending an intentional HTTPS-only browser instruction on the checked response.

Why agencies should review HSTS on client websites

Agencies often inherit mixed hosting responsibilities. A site may be built by one team, hosted by another provider, routed through a CDN, and managed in DNS by the client or MSP. HSTS can be configured at several layers: CDN, web server, framework middleware, hosting control panel, or reverse proxy.

Review HSTS during:

• Launch QA.
• Client handover.
• Hosting migrations.
• CDN onboarding.
• New-client technical onboarding.
• Monthly care-plan review.
• HTTPS redirect cleanup.

The value is practical. If HSTS is missing, the agency can ask the right owner to review it. If HSTS is present with broad settings, the agency can confirm that subdomains and certificates are ready for those settings.

The HSTS fields agencies should understand

| HSTS signal | What it means | Common finding | Agency action | |---|---|---|---| | Header present | The HTTPS response sends Strict-Transport-Security | Present on homepage only | Ask whether key public routes share the same behavior | | max-age | Browser memory period in seconds | Very short, absent, or very long | Confirm whether the value is intentional | | includeSubDomains | Applies the policy to subdomains | Present without known subdomain review | Ask DNS, host, or IT owner to confirm coverage | | preload | Site signals intent for browser preload lists | Present without clear ownership | Confirm the organization understands the operational commitment | | Header missing | No HSTS signal on the checked HTTPS response | Common on managed hosts or new launches | Treat as a recommended improvement, not a final judgment |

max-age

max-age is the required HSTS directive. It is measured in seconds. For example, max-age=31536000 means one year.

Agencies should not treat a single number as universally correct. A very short value may be used during rollout. A longer value may be reasonable for a stable site where HTTPS is consistently available. The important review question is: "Does this value look deliberate, and does the owner understand the effect?"

If max-age is missing, malformed, or unexpectedly short, document the observed value and ask the developer or host to review the HSTS configuration.

includeSubDomains

includeSubDomains extends HSTS behavior beyond the exact hostname to subdomains. That can be appropriate when the organization has confirmed that every relevant subdomain is ready for HTTPS-only behavior.

For client websites, this directive deserves extra care. Agencies may not know about old campaign subdomains, third-party portals, legacy redirects, regional hostnames, or client-managed systems. If includeSubDomains is present, ask who verified the subdomain inventory. If it is absent, do not automatically recommend adding it without that review.

preload

The preload directive is a signal used when a site wants inclusion in browser HSTS preload lists. This is an operational commitment and should be owned by someone with DNS, certificate, hosting, and subdomain context.

In an agency report, phrase preload carefully:

• "HSTS preload signal is present; confirm ownership and readiness."
• "HSTS preload signal is absent; no action unless the client has a deliberate preload plan."

Avoid making preload a default launch requirement for every client site.

Common HSTS review findings

Common findings include:

• HSTS is missing on the checked HTTPS response.
• HSTS is present but max-age is very short.
• HSTS is present on www but not the apex domain, or the reverse.
• HSTS is added by a CDN but not by origin responses.
• includeSubDomains appears on a domain with unknown subdomains.
• preload appears without a documented owner.
• HTTP redirects work, but HSTS is absent.

Each finding should become a short handover item. Include the URL, exact observed header, and likely owner.

When a missing HSTS signal matters

A missing HSTS signal matters most when the site is public, stable, HTTPS-first, and under ongoing care. It is especially worth reviewing after launch, after a host move, or when an agency is preparing a client website quality report.

It may be less urgent during early staging, temporary microsites, complex migrations, or environments where HTTPS coverage is still being confirmed. That does not mean ignoring it. It means recording it as a recommended improvement with context.

When HSTS needs developer or hosting review

Involve a developer, host, or CDN owner when:

• The header is missing and the team does not know where headers are managed.
• The value differs between www and apex.
• The site uses multiple applications under one domain.
• includeSubDomains is present.
• preload is present or requested.
• Redirect behavior is inconsistent.

The handoff should be specific: "On the checked HTTPS response, Strict-Transport-Security was not detected. Please review whether an HSTS policy should be added at the CDN, host, or app layer."

HSTS review checklist for agencies

• Check the final production URL, not only staging.
• Record whether the checked response uses HTTPS.
• Record whether HTTP redirects to HTTPS.
• Record the exact Strict-Transport-Security value if present.
• Review max-age.
• Review whether includeSubDomains is present.
• Review whether preload is present.
• Confirm who owns CDN, host, app, and DNS settings.
• Avoid broad subdomain recommendations without subdomain context.
• Add the finding to handover or care-plan notes.

What Client Website Trust Check reports

The Client Website Trust Check reports whether an HSTS signal is visible on the public response being checked. It places that finding alongside other public trust signals such as HTTPS/TLS, redirect behavior, selected headers, visible cookie flags, CAA, robots.txt, sitemap.xml, and security.txt.

This is useful because HSTS rarely belongs in isolation. If a site lacks HSTS but also has redirect or certificate issues, the owner should usually resolve the HTTPS foundation first.

What a passive public check cannot prove

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.

A passive public check cannot prove that every route sends the same header, that every subdomain is ready for includeSubDomains, or that preload is appropriate. For CertPilot's public-check approach and limitations, see the methodology page.

Related Resources

• Website header checklist for agencies
• Client website trust signals guide
• Website trust signals checker
• Client website trust checklist

Frequently Asked Questions

What is an HSTS checklist for agencies?

An HSTS checklist for agencies is a practical review of the public Strict-Transport-Security header on a client website. It checks whether the header is present, what max-age value is visible, and whether includeSubDomains or preload appear. The checklist helps agencies create a clear recommendation for the host, CDN owner, or developer.

Should every client website have HSTS?

Most stable HTTPS-first public sites should have HSTS reviewed, but the exact policy should match the site. A simple marketing site may be straightforward. A domain with many subdomains, legacy systems, or mixed ownership needs more care before broad directives are added. Agencies should recommend review, not apply one value everywhere.

Is includeSubDomains always a good idea?

No. includeSubDomains can affect hostnames the agency may not manage. Before recommending it, confirm subdomain inventory, certificate coverage, redirects, and ownership. If nobody can confirm those details, the safer agency action is to ask for developer, host, or IT review rather than adding the directive by default.

What max-age should an agency expect?

There is no single value that fits every client site. Short values may appear during rollout, while longer values may be used once HTTPS behavior is stable. The agency should flag absent, malformed, unusually short, or unexplained values and ask the responsible technical owner to confirm the intended policy.

Does a missing HSTS header mean the site failed review?

No. A missing HSTS header is a missing public trust signal and a recommended improvement. It does not prove the whole site has a broader problem. The next step is to check who controls headers and whether the site is ready for an HSTS policy.

Can Client Website Trust Check prove HSTS is set everywhere?

No. It checks the public URL submitted and reports what is visible in that response. It does not crawl every route, log in, inspect private pages, or verify every subdomain. Use the result as a first-pass agency client review item, then involve the owner of the hosting stack when needed.