Client Website Trust Checklist: A 60-Second Review for Agencies

A client website trust checklist is a short public review of HTTPS/TLS, certificate expiry, redirect behavior, response headers, CAA, robots.txt, sitemap.xml, and security.txt. Agencies can run it in about a minute during onboarding, handover, care-plan reviews, and after hosting or DNS changes.

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

The goal is not to prove everything about the site. The goal is to produce a factual public signal review that can be sent to a developer, host, DNS owner, or client stakeholder. Start with the Client Website Trust Check, then use the free 10-domain audit when the conversation expands from one site to a portfolio.

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

Quick answer: the 60-second client website trust checklist

For one client website, check:

• Public HTTPS response.
• HTTP-to-HTTPS redirect.
• TLS certificate expiry.
• HSTS and common response headers.
• Visible cookie flags on the first public response.
• CAA DNS record.
• robots.txt.
• sitemap.xml.
• /.well-known/security.txt.

If any item is missing or unknown, note the likely owner: developer, host, CDN, DNS provider, or client IT.

When agencies should run this check

Run the checklist at moments where responsibility changes or client confidence matters:

| Review moment | What to check | Why it matters | Next step | |---|---|---|---| | Before handover | HTTPS, TLS, headers, metadata files | Avoids visible gaps after launch | Add findings to handover notes | | New-client onboarding | Certificate expiry, CAA, DNS ownership | Shows inherited operational risk | Assign owners for follow-up | | Care-plan renewal | Public trust signals and certificate runway | Gives the client proof of ongoing review | Include in monthly proof report | | Hosting change | Redirect, headers, certificate issuer | Defaults may change during migration | Compare before and after | | DNS change | CAA, www, redirect behavior | DNS edits can affect certificate renewal | Confirm with DNS owner | | Launch QA | robots.txt, sitemap, headers | Production may differ from staging | Run check on final live URL |

Before client handover

Handover is the best time to catch small public gaps. The client is focused on whether the site is ready, the agency still has project context, and the developer or host can usually make changes quickly.

Include these notes in the handover pack:

• Public URL checked.
• Date checked.
• Certificate expiry date or days remaining.
• Redirect behavior.
• Header findings.
• Public metadata files found.
• CAA status.
• Follow-up items and owners.

This turns a vague QA promise into a repeatable review.

During new-client onboarding

New-client onboarding is different from launch QA. The agency is inheriting a website, often without knowing who controls DNS, hosting, certificate automation, or CDN settings.

Use the checklist to identify ownership questions:

• Who owns DNS?
• Who owns hosting?
• Who renews or automates certificates?
• Is there a CDN?
• Are headers controlled by the app, host, or edge layer?
• Where is the sitemap generated?
• Who receives reports sent through security.txt if it exists?

The check does not answer every ownership question, but it shows which public signals need attention.

Before care-plan renewal

Care-plan renewal conversations benefit from proof. Clients may not see the value of operational checks unless the agency shows what was reviewed and why it matters.

Use a trust-signal checklist as a short section in a proof report:

• Present signals.
• Missing signals.
• Unknown signals.
• Recommended improvements.
• Items completed since last report.

For report structure, see the client website health report template and monthly proof report guide.

After hosting or DNS changes

Hosting and DNS changes are high-signal moments because defaults can change without the visual site changing. A migration may alter redirect rules, certificate issuer, response headers, cookie behavior, sitemap generation, or CAA records.

Run the checklist before and after the change. If the after-check differs, decide whether the difference is expected. This is especially useful when the client owns DNS and the agency owns the website implementation.

The 60-second checklist

1. Submit the public URL to the trust check.
2. Confirm HTTPS works and HTTP redirects as expected.
3. Check certificate expiry runway.
4. Review the header section.
5. Review visible cookie flag recommendations.
6. Confirm robots.txt and sitemap.xml are reachable.
7. Check whether security.txt exists.
8. Review CAA records.
9. Assign each follow-up item to the right owner.
10. Save the summary in the client notes.

This workflow is intentionally small. It is easier to repeat every month than a long checklist that nobody runs twice.

What to document for the client

Clients do not need raw headers pasted into a report. They need clear findings:

• "HTTPS redirect is present."
• "Certificate expires in X days."
• "CAA records should be reviewed with DNS owner."
• "security.txt was not found; optional contact file can be added."
• "CSP was not detected; developer should review whether a policy is appropriate."

Avoid alarm-heavy wording. Keep it factual and tied to recommended improvement.

What to send to a developer or host

Developers and hosts need more precise detail:

• URL checked.
• Header name and observed value.
• Missing signal.
• Cookie name if visible and relevant.
• Redirect behavior.
• CAA record value.
• Desired outcome.

If the site uses a CDN, include that in the request. Headers may be set at the edge rather than in the app.

What this checklist cannot prove

A short public checklist cannot inspect logged-in areas, test every route, run JavaScript, evaluate every cookie, or review server-side configuration.

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.

For CertPilot's public-check approach and limitation notes, see the methodology page.

How to run the free Client Website Trust Check

Open the Client Website Trust Check, enter the client's public URL, and review the score, grade, category breakdown, and recommendations. Use the result as a first-pass QA artifact.

For a single domain's broader SSL, DNS, and expiry view, you can also run the single domain health check. For shorter certificate renewal readiness, use 47-Day Pre-Flight.

How to scale from one site to a 10-domain audit

Once the client has more than one domain, move from a single-site checklist to a portfolio review. Use the free 10-domain agency audit for a combined view of SSL certificate status, domain expiry, DNS basics, CAA, and email-authentication summary.

Use the trust checklist for the most important live URLs, such as the homepage, contact page, lead form, pricing page, or client portal entry point.

Related Resources

• Website trust signals checker
• Client website health report template
• Monthly proof reports for agencies
• Domain expiry monitoring for agencies

Frequently Asked Questions

What is a client website trust checklist?

A client website trust checklist is a short public review of signals such as HTTPS/TLS, certificate expiry, redirect behavior, headers, CAA, robots.txt, sitemap.xml, and security.txt. It helps agencies document public website posture before handover, during onboarding, and inside recurring care-plan reviews.

How long should this review take?

The first pass should take about a minute per site when using a tool. Follow-up may take longer if the findings involve DNS ownership, host settings, CDN configuration, or developer work. The point is to separate fast detection from slower ownership resolution.

Should this checklist be part of every launch?

Yes, for most agency workflows. It is small, repeatable, and easy to document. Run it on the final production URL, not only on staging. If the production host or CDN differs from staging, the public signals may differ too.

What should agencies do with missing signals?

Assign each missing signal to an owner. Headers often go to the host, CDN, or developer. CAA goes to the DNS owner. Sitemap and robots issues often go to the CMS or SEO owner. security.txt may need client approval because it contains public contact details.

Is this checklist enough for a care-plan report?

It can be one section of a care-plan report. Pair it with SSL expiry, domain expiry, DNS changes, and email-authentication checks for a broader operational view. The checklist is best used as evidence of public website review, not as the entire report.

Why does the checklist include security.txt?

security.txt is a public contact file. It helps route responsible reports to the right inbox. It is optional, but useful for organizations that want a clear public reporting path. Agencies should confirm the contact address and process before publishing it.