Referrer-Policy for Agencies: A Practical Website Header Review

Referrer-Policy controls how much referrer information a browser may send when users move from one page or site to another. For agencies, reviewing Referrer-Policy means checking whether a client website sends an intentional public header instead of relying only on browser defaults.

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

Use CertPilot's Client Website Trust Check to review Referrer-Policy as part of header hygiene for one public URL. Use the free 10-domain agency audit when the client conversation also needs SSL, DNS, domain expiry, CAA, and email-authentication signals across multiple domains.

Quick answer: Referrer-Policy for agencies

For an agency header review, Referrer-Policy answers one practical question: does the client site explicitly control the referrer details browsers may send during navigation?

The review should capture:

• Whether the Referrer-Policy header is present.
• The exact policy value.
• Whether the value makes sense for the site type.
• Whether analytics or attribution owners need to confirm the setting.
• Whether the policy is controlled by the app, CDN, host, or framework.

The most common modern value agencies will see is strict-origin-when-cross-origin, but other values may be appropriate depending on the site and product context.

What Referrer-Policy controls

When a person clicks from one page to another, browsers may send referrer information to the destination. That information can include the previous page URL or only part of it, depending on the policy.

Referrer-Policy lets the website state how much of that information should be shared. MDN's Referrer-Policy reference lists the available values and their browser behavior.

For agencies, the header is a public trust signal because it shows whether the site is making an explicit choice about referrer behavior.

Why agencies should include it in website header reviews

Referrer-Policy is easy to miss because it does not change the visual design of the page. It may be set by a hosting platform, a CDN rule, an application framework, or a plugin. In a client handover, the agency should know whether the public response includes it.

Review it during:

• Launch QA.
• Header hygiene review.
• Client onboarding.
• Analytics implementation review.
• CDN or hosting migration.
• Care-plan reporting.

The finding should be framed calmly: present, missing, or needs owner review.

Common Referrer-Policy values

| Policy value | Plain-English behavior | Common use | Agency note | |---|---|---|---| | strict-origin-when-cross-origin | Sends full URL on same-origin requests, origin only cross-origin over HTTPS | Common baseline for modern sites | Often reasonable, but confirm attribution needs | | no-referrer | Sends no referrer information | Privacy-sensitive flows | May affect analytics and referral reporting | | same-origin | Sends referrer only within the same site | Apps that want limited sharing | Confirm cross-site attribution impact | | origin | Sends only the origin, not full path | Sites wanting reduced detail | Useful middle ground in some cases | | no-referrer-when-downgrade | Sends referrer except from HTTPS to HTTP | Older default-style behavior | May be less intentional than newer values |

strict-origin-when-cross-origin

strict-origin-when-cross-origin is commonly seen because it gives detail within the same site while limiting detail sent to other origins. It can be a practical default for many client websites.

Agencies should still avoid treating it as universally correct. Ecommerce, SaaS apps, marketing attribution, embedded apps, and portals may have different expectations. If the client relies on detailed cross-site attribution, involve the analytics owner before changing policy.

no-referrer

no-referrer is restrictive. It tells the browser not to send referrer information. This can fit certain privacy-sensitive flows, but it can also affect analytics, campaign reporting, partner referrals, and debugging.

If this value appears unexpectedly, do not assume it is wrong. Document it and ask whether the marketing, analytics, or product owner expects that behavior.

same-origin

same-origin allows referrer information only for same-origin requests. It can be useful where the site wants internal navigation context but does not want to share referrer information with other sites.

For agencies, the main action is to confirm whether the client has any cross-domain measurement or partner integration that depends on referrer data.

origin

origin sends only the scheme, host, and port. It avoids sharing the full path while still telling the destination which site the visitor came from.

This can be a reasonable option for some public sites, but the correct value depends on client needs. Record the value and confirm with the owner before recommending a change.

What a missing Referrer-Policy signal means

A missing Referrer-Policy header means the checked public response did not send an explicit policy. It should be treated as a missing signal and a recommended improvement, not as a broad conclusion about the whole site.

The site may rely on browser defaults, a meta tag, route-specific headers, or a policy applied somewhere else. A passive public check can only report what is visible on the checked response.

Referrer-Policy review checklist

• Check the final production URL.
• Record whether Referrer-Policy is present.
• Record the exact value.
• Identify whether the site uses analytics, ads, affiliate links, partner redirects, or product flows that need owner review.
• Confirm whether headers are set by the app, CDN, host, or framework.
• Avoid changing policy without analytics and developer context.
• Add the finding to the client handover or care-plan report.

How to review Referrer-Policy with a developer or host

Send a short, specific note:

"The checked public response did not include a Referrer-Policy header. Please review whether the site should send an explicit policy such as strict-origin-when-cross-origin, taking analytics and product requirements into account."

If a value is present, send:

"The checked public response includes Referrer-Policy: [value]. Please confirm this is intentional for the site and compatible with analytics and attribution needs."

What Client Website Trust Check reports

The Client Website Trust Check reports whether a Referrer-Policy signal is visible on the submitted public URL. It also reviews other public trust signals such as HSTS, Permissions-Policy, CSP presence, visible cookie flags, HTTPS/TLS, CAA, and public metadata files.

That makes Referrer-Policy part of a practical header hygiene review rather than a stand-alone project.

What this 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 route-by-route behavior, browser meta tag behavior, analytics impact, or whether the chosen value is best for the client's business model. For CertPilot's approach to public data and limitations, see the methodology page.

Related Resources

• Website header checklist for agencies
• Client website trust checklist
• Client website trust signals guide
• Agency client reporting guide

Frequently Asked Questions

What is Referrer-Policy for agencies?

Referrer-Policy for agencies is a practical header hygiene check that confirms whether a client website explicitly controls referrer information. The agency records the visible header value, checks whether it appears intentional, and routes questions to the developer, host, CDN owner, or analytics owner.

Is strict-origin-when-cross-origin the best value?

It is a common modern value and often a reasonable baseline, but it is not automatically best for every site. The right policy depends on analytics, product flows, partner links, and privacy expectations. Agencies should recommend review rather than changing values without context.

What does a missing Referrer-Policy header mean?

It means the checked public response did not expose an explicit Referrer-Policy header. Treat it as a missing signal and a recommended improvement. It does not prove how every route behaves, and it does not show whether a meta tag or another layer affects behavior elsewhere.

Who should approve a Referrer-Policy change?

Usually the developer or host implements the header, but marketing, analytics, or product owners may need to approve the value. A restrictive policy can affect attribution and reporting. The agency should identify both the technical owner and the business owner before changing the policy.

Can this check inspect referrer behavior after login?

No. A passive public check only reviews the visible response for the submitted public URL. It does not log in, interact with private routes, run user flows, or test analytics events. Logged-in apps need separate product-specific QA.

Should agencies include Referrer-Policy in client reports?

Yes, as a concise public trust-signal item. Use factual language such as "Referrer-Policy is present with value X" or "Referrer-Policy was not detected on the checked response." Then assign any recommendation to the correct owner.