Client Website Trust Signals Guide for Agencies

Client website trust signals are public indicators such as HTTPS/TLS, certificate expiry, redirect behavior, header hygiene, cookie flags, CAA, robots.txt, sitemap.xml, and security.txt. These signals help agencies review public website posture, assign recommended improvements, and explain what was checked during handover or care-plan reporting. They do not provide a complete answer about every private route, app behavior, or legal requirement.

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

Use the Client Website Trust Check for a fast passive public check on one domain or URL. Use the free agency audit when the review should cover up to 10 domains with SSL, DNS, domain expiry, CAA, and email-authentication signals.

Quick answer: client website trust signals

Client website trust signals are public signals a normal external check can observe. They are useful because agency teams can review them without logging in, crawling private pages, or relying on client access.

The main signals are:

• HTTPS/TLS response.
• Certificate expiry.
• HTTP-to-HTTPS redirect behavior.
• Header hygiene.
• Cookie flags visible on the public response.
• robots.txt.
• sitemap.xml.
• security.txt.
• CAA DNS records.

The review should produce a score, grade, category summary, and recommended improvements. It should also show unknowns honestly.

Why agencies should review public trust signals

Agencies review public trust signals because they are visible to clients, browsers, crawlers, tools, and technical reviewers. A missing signal can create a support question even when the visual site looks finished.

Use trust-signal review during:

• Client handover.
• New-client onboarding.
• Care-plan renewal.
• Hosting changes.
• DNS changes.
• Launch QA.
• Monthly proof reporting.

The support article website trust signals checker gives the shorter checklist. This pillar organizes the full cluster.

HTTPS and TLS signals

HTTPS and TLS signals show whether the public URL responds over TLS, which certificate is visible, and how much expiry runway remains.

| Trust signal | What it shows | Why agencies should review it | Tool/check | |---|---|---|---| | HTTPS response | Public URL responds over TLS | Basic public posture signal | Trust Check | | Certificate expiry | Days remaining | Prevents surprise renewal work | Trust Check, Audit | | Issuer | Visible certificate provider | Helps identify hosting or CA path | Audit | | HTTP redirect | HTTP moves to HTTPS | Confirms public redirect behavior | Trust Check | | CAA | CA authorization in DNS | Supports certificate readiness review | Trust Check, Pre-Flight |

For deeper SSL operations, use SSL monitoring for web agencies. For CAA and renewal readiness, use CAA records and 47-day SSL.

HTTPS redirect behavior

Redirect behavior matters because visitors, tools, and old links may still request http://. The expected result for most client sites is a clean move to https://.

When a redirect is missing or unclear, the next owner is usually the host, CDN, web server, or application framework. The agency should document the checked URL, observed behavior, and recommended improvement.

Header hygiene signals

Header hygiene covers public response headers such as HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, CSP presence, and framing controls.

The website header checklist explains these signals in detail. The practical rule is to avoid overclaiming. A header can be present and still need deeper developer review. A missing header should be treated as a recommended improvement, not a broad judgment about the whole site.

Cookie flag signals

Some public pages set cookies for analytics, consent, personalization, or application sessions. A passive public check can only review cookies visible in the checked response.

That means cookie results should be framed carefully:

• Visible flags can be reviewed.
• Cookies set after JavaScript runs may not appear.
• Cookies set after login are outside this check.
• Unknown results may need browser or app-specific QA.

Public metadata files: robots.txt, sitemap.xml, security.txt

Public metadata files help tools and people understand the site:

• robots.txt gives crawler instructions.
• sitemap.xml supports URL discovery.
• security.txt gives a public contact path for reports.

The security.txt for agencies article explains how that file should be handled. It is one public signal among several, not a stand-alone proof item.

DNS trust signals: CAA records

CAA records tell certificate authorities which CAs may issue certificates for a domain. For agencies, CAA is useful because DNS ownership and certificate automation often sit with different people.

Use CAA records that block Let's Encrypt when a Let's Encrypt workflow is involved, and use Pre-Flight when certificate renewal readiness needs deeper review.

What a passive public check can catch

A passive public check can catch:

• Missing HTTPS redirect.
• Certificate near expiry.
• Missing header signal.
• Missing public metadata file.
• Visible cookie flag issue.
• Missing or unexpected CAA signal.
• Unknown result caused by blocked or unusual public response.

What a passive public check cannot catch

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 data-source boundaries, see the methodology page.

How Client Website Trust Check fits

Client Website Trust Check is the single-site workflow for public trust signals. It accepts one public domain or URL and returns a score, grade, category breakdown, recommendations, and disclaimer.

Use it when the question is: "What public trust signals are visible on this client site?"

When to use Trust Check vs Health Check vs Pre-Flight vs Audit

| Tool | Best for | What it checks | Limitation | |---|---|---|---| | Trust Check | Public trust signals on one site | HTTPS/TLS, headers, cookies, metadata files, CAA | Passive public check only | | Health Check | One domain health snapshot | SSL, DNS, RDAP/domain, OCSP | Not a header hygiene workflow | | Pre-Flight | 47-day SSL readiness | ACME, CAA, redirect, renewal readiness | Focused on certificate workflow | | Agency Audit | Multi-domain client review | SSL, DNS, domain expiry, email-auth summary | Portfolio view, not page-specific |

Decision framework:

• Use Trust Check for handover and public website posture.
• Use Health Check for one domain's SSL, DNS, and domain status.
• Use Pre-Flight for CAA and ACME readiness.
• Use Audit for multi-domain client reporting.

How trust signals support client reporting

Trust-signal results should become short client-facing proof:

• Public HTTPS/TLS checked.
• Header hygiene reviewed.
• Public metadata files checked.
• CAA reviewed.
• Recommended improvements assigned.

| Missing signal | Possible explanation | Recommended improvement | Confidence | |---|---|---|---| | No redirect | Host or CDN rule absent | Ask host/developer to review redirect behavior | High | | Header absent | Not configured at edge or app | Ask host/developer to add tested header | Medium | | No security.txt | No public contact file | Confirm whether client wants one | High | | No sitemap | CMS or SEO setting missing | Ask SEO/CMS owner to review | Medium | | Unknown result | Request blocked or unusual response | Verify manually and document context | Low |

Use monthly proof reports and the client website health report template to convert findings into client-ready language.

Client website trust-signal review checklist

• Check the production URL.
• Confirm HTTPS/TLS response.
• Review certificate expiry.
• Check HTTP-to-HTTPS redirect behavior.
• Review header hygiene signals.
• Review visible cookie flags.
• Check robots.txt.
• Check sitemap.xml.
• Check security.txt.
• Review CAA DNS records.
• Classify missing signals as action, unknown, or accepted.
• Assign each recommended improvement to an owner.
• Add client-facing proof to the report.

Cluster map: supporting Trust Check resources

• Website trust signals checker
• Website header checklist for agencies
• Client website trust checklist
• security.txt for agencies
• CAA records and 47-day SSL
• CAA record blocks Let's Encrypt
• Client website health report template
• Monthly proof report for agencies
• DNS drift agency guide
• Agent-friendly web page checklist

Related Resources

• Website trust signals checker
• Website header checklist for agencies
• Client website trust checklist
• security.txt for agencies
• Client website health report template

Frequently Asked Questions

What are client website trust signals?

Client website trust signals are public indicators such as HTTPS/TLS, certificate expiry, redirect behavior, header hygiene, cookie flags, CAA, robots.txt, sitemap.xml, and security.txt. They help agencies review public website posture and identify recommended improvements before handover, onboarding, or reporting conversations.

How is Trust Check different from Health Check?

Trust Check focuses on public trust signals such as headers, metadata files, cookie flags, HTTPS/TLS, and CAA. Health Check focuses on one domain's SSL, DNS, RDAP/domain, and OCSP-style health signals. Use Trust Check for handover-style public posture review and Health Check for a domain health snapshot.

Does a missing signal always require immediate action?

No. A missing signal should be reviewed in context. Some sites intentionally omit a signal, some signals are configured elsewhere, and some checks may return unknown because the public response is blocked or unusual. The agency should classify the finding, assign an owner, and decide whether it belongs in the client report.

Why does security.txt matter in this workflow?

security.txt gives a public contact path for reports. It is useful when the client has an owner for the inbox and a process for triage. It is not a stand-alone quality proof. It should be reviewed alongside HTTPS/TLS, headers, CAA, robots.txt, and sitemap.xml.

How should agencies report trust-signal findings to clients?

Keep the language factual. Say what was checked, what was present, what was missing, what was unknown, and who owns the recommended improvement. Do not paste raw headers without interpretation. The client should understand the next action, not decode the technical output.

Can Trust Check inspect private pages?

No. Trust Check is a passive public check. It reviews what is visible from a small number of public requests to the submitted domain or URL. It does not log in, inspect private pages, run browser rendering, or crawl the whole site.