HTTP Header Checker

Free, no signup. See the headers browsers and crawlers receive: every redirect hop, separate security and SEO grades, edge fingerprints, compression, and an honest HTTP/3 signal.

Built by Patrick Stox

Request user-agent

A matching user-agent does not make this request originate from that crawler’s verified IP range.

This makes two user-triggered requests for one URL from Cloudflare infrastructure. It compares user-agent responses, not verified crawler behavior or crawler IP access.

Compare staging or another URL

The report compares the final response headers from two independent checks.

Checks run from our server; we fetch the URL you enter and don't keep the results. Complete response header maps are returned to your browser. Repeating the same URL and user-agent within about ten minutes may reuse a short-lived edge cache. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback
Report a bug

Found something broken in Http Header Checker? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
   
 
 Compare common headers across up to five URLs    
Frequency is calculated in this browser from the live final responses in this run. It is not a global popularity dataset.
   
 
 
Sample report
Illustrative example — exact grading for the fixed header map below
HTTP/2 200
strict-transport-security: max-age=31536000
cache-control: public, max-age=3600
etag: "abc123"
Security headers
F40/100
HSTS passes. Missing CSP fails; missing framing protection, Referrer-Policy, nosniff, Permissions-Policy, and COOP are warnings. Missing COEP is informational.
SEO headers
A+100/100
Cache-Control and ETag pass. Missing X-Robots-Tag, Link canonical, and Vary are informational in this HTTP-only grade.
The displayed HTTP/2 line is illustrative input only: the live Worker cannot expose the negotiated HTTP version.
 
 
 
How to use it
 
  1. Enter a public URL and choose the browser, search-crawler, or AI-crawler user-agent you want to send.
  2. Optionally add a staging or comparison URL; only final-response headers are diffed.
  3. Choose Check headers, start with the two grades, then inspect the exact finding and header evidence.
  4. Review every redirect response and use the raw curl-style view when you need to copy the complete observed map.
 
 
 
     
     
     
 
What the results mean
  • Security grade deducts 20 points per failure and 8 per warning across the implemented header rules.
  • SEO grade evaluates X-Robots-Tag, Link canonical and hreflang, Vary, cache directives, and ETag.
  • Pass confirms one rule; info is context without a score penalty.
  • Delivery fingerprint is evidence about a public edge, not proof of the origin host.
  • Comparison lists changed final-response header values, not HTML or behavior differences.
 
How it works
A bounded server-side checker sends the selected user-agent, records each redirect response without hiding intermediate headers, and returns normalized header maps and timings. Browser-side functions grade the final response, parse Link headers, inspect compression and protocol advertisements, identify a small set of edge fingerprints, produce a curl-style view, and diff an optional second final response. The small batch mode counts fields only across the final responses fetched in that run and labels names from a local status-preserving snapshot of the IANA HTTP Field Name Registry.
 
Features
  • Complete headers for every observed redirect hop.
  • Separate deterministic security and HTTP-level SEO grades.
  • Browser, Googlebot, and supported crawler user-agent choices.
  • Compression, edge fingerprint, and honest HTTP/3 advertisement facts.
  • Optional final-response environment diff and raw header export view.
  • Session-local common-header frequency for up to five URLs.
 
Limitations
 
The report cannot expose negotiated HTTP version, TLS certificate details, private origin infrastructure, or headers added only inside a user's network. The Fetch Headers API may combine repeated field lines: parsed combined values are assessed, but the original field-line order and boundaries cannot be reconstructed. User-agent strings originate from a Cloudflare datacenter, not verified crawler IP ranges. It does not inspect HTML metadata, application security, or whether a 200 body is correct.
 
Frequently asked questions
 
Does the tool preserve repeated header field lines?
Not exactly. The Worker Fetch Headers API exposes a normalized, potentially combined value. The checker parses and assesses that combined value, but it cannot reconstruct the original order or boundaries of repeated field lines.
Does this show the HTTP version?
Workers do not expose the negotiated HTTP version. The tool only reports when Alt-Svc advertises HTTP/3; that is not proof this request used HTTP/3.
Why do browser and Googlebot results differ?
Sites can vary headers by user-agent. This sends the selected user-agent string from a Cloudflare datacenter, not from a verified crawler IP rangeA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index..
Are URLs saved?
No. The URL is fetched to build this report and a short-lived edge cache may reuse the same URL and user-agent response for about ten minutes.
Is a high security-header grade proof that a site is secure?
No. The grade covers a defined set of public response headers. It does not test application vulnerabilities, authentication, server configuration, dependency risk, or whether a policy works correctly for the application.
Does the SEO grade inspect HTML canonical and robots tags?
No. It evaluates HTTP-level signals such as X-Robots-TagThe X-Robots-Tag is an HTTP response header that carries the same indexing and serving directives as the robots meta tag (noindex, nofollow, nosnippet, and the rest). Because it lives in the header rather than the HTML, it's how you control indexing for non-HTML files like PDFs, images, and videos. and Link headers. Page-level canonical and robots elements require an HTML-aware checker.
 
Next stepHosting Checker — look up the exact spec and expected values.

Explore more
ToolDNS CheckerToolWebsite Down CheckerToolDomain ReportArticleMixed ContentArticleCaching for SEOArticleWebsite Hosting Migration SEO
 
 
 
Feature requests for Http Header Checker
 

Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
      requests appear here once approved, and the most-wanted rise to the top.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
    
 
 
        
 
Common issues & how to fix them
 
 
 
 
 
HTTP Header Checker · one finding
 
X-Robots-Tag blocks indexing
 
Recommended action: Remove noindex from the X-Robots-Tag on URLs intended for search, then verify the final response and request recrawling.
 
Fix principle: Remove every unintended noindex from its confirmed owner; absence of noindex is sufficient, while an explicit index directive cannot override another noindex because restrictive directives combine.
 
 
 
 Implementation for your setup 
 
Confirm first: The final HTML or HTTP response contains a noindex directive, including one added only by client-side script during rendering. The page is intended to be an indexable canonical URL. A robots meta tag or X-Robots-Tag intended to keep the page indexable is neutralized by a conflicting directive elsewhere, because directives combine using the most restrictive rule. Robots.txt disallows the URL itself, or disallows a resource the page depends on to render, so the crawler cannot reach or fully evaluate the intended indexable page.
 
Do not apply when: Exclusion is intentional for the page type, environment, or workflow state. The directive appears only on a noncanonical or otherwise ineligible URL. Robots.txt does not disallow the URL or the resources it needs to render, and the effective combination of every directive already resolves to the intended indexable state.
 
Likely control points: cms-app · server · edge-cdn
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The application, server, or edge owner that emits the directive, or the robots.txt file at the site root
 
Steps
  1. Follow redirects, identify the exact owner of each unintended robots/googlebot meta or X-Robots-Tag noindex, and remove it only at that owner.
  2. Return the intended canonical page with a crawlable 200 response, align its canonical, and purge the caches that can retain the directive.
  3. If a robots meta tag or X-Robots-Tag is present but rendered ineffective by a conflicting directive elsewhere, remove the actual unwanted restrictive directive rather than adding a permissive one to compete with it — the most restrictive rule always wins. Google also honors a robots meta tag placed outside <head>, so an out-of-head placement is a specification and cross-crawler risk to correct, not by itself proof Google is ignoring the directive.
  4. If robots.txt disallows the URL itself, or disallows a resource (such as CSS or JS) the page needs to render its content, correct only the specific Disallow rule at the robots.txt file that owns it — keep the rule as narrow as its original intent, and remember Disallow blocks crawling, not indexing: a disallowed URL can still be indexed if discovered elsewhere.
  5. Keep the URL crawlable so Google can observe the removal.
  
Verify on this platform
 
  • After redirects and cache purge, inspect every robots and googlebot meta tag plus every X-Robots-Tag value on the final response.
  • Fetch and parse robots.txt for every group that applies to the relevant user-agent — Google consolidates every group matching the same user-agent token into one effective ruleset, though not every crawler does — and confirm the URL and its critical rendering resources are not disallowed.
  • Use Search Console URL Inspection’s live test on the production URL, then request indexing when appropriate.
 
Rollback
  1. Restore the prior directive or robots.txt rule if the page or a resource it needs was exposed or blocked unintentionally, then correct the underlying publication rule before trying again.
 
Caveats
  • Do not add index as a counter-directive: the most restrictive directive applies, so another noindex still wins.
  • The live test checks current accessibility; it does not guarantee selection, canonical choice, or indexing.
  • Google’s own parser combines every robots.txt group matching the same user-agent token into one effective ruleset, but many other crawlers and Robots Exclusion Protocol implementations honor only the first matching group — treat a directive split across groups as a real interoperability risk even when Google itself is unaffected.
  • If the page combines a canonical to a different URL with a noindex directive, remove the noindex only if this URL itself should be indexable; if the canonical target is the one meant to be indexed, keep the noindex here and verify the canonical target separately rather than treating its indexability as confirmed by removing this noindex.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Global Settings → Reading/blog_public, or the scoped plugin/theme callback that owns wp_robots
 
Steps
  1. If WordPress core globally owns the directive, confirm the scope and change Settings → Reading so blog_public permits search-engine visibility.
  2. For a scoped page-type or URL rule, identify and change the plugin or theme callback filtering wp_robots or invoking the core noindex behavior; do not invent a plugin UI.
  3. Purge page, object, host, and edge caches that can retain the old output.
  
Verify on this platform
 
  • While logged out, follow redirects and inspect all robots/googlebot meta plus X-Robots-Tag values on the final public response.
 
Rollback
  1. Restore the previous visibility or plugin setting if unintended pages become indexable.
 
Caveats
  • Do not use the global Reading setting to solve a scoped plugin or theme rule.
  • WordPress exposes the wp_robots API, but a third-party owner’s exact UI is not verified here.
  • Robots.txt is a separate control point from this meta/header directive — correct a Disallow rule using the generic-http-html guidance above regardless of which CMS serves the site.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Confirmed Response Header Transform Rule or Worker emitter
 
Steps
  1. Use Cloudflare Trace and configuration review to confirm which Transform Rule or Worker adds the final X-Robots-Tag and account for response-header rule ordering.
  2. Narrow or remove only that confirmed edge emitter; in a Worker, clone the response before modifying its headers.
  3. Purge the affected cache entries and leave any valid origin-owned robots header intact.
  
Verify on this platform
 
  • Compare origin and final Cloudflare responses after redirects, then confirm every final robots header and meta directive is free of unintended noindex.
 
Rollback
  1. Restore the prior edge rule if the scope change exposes excluded routes, then replace it with a narrower condition.
 
Caveats
  • Never blanket-delete a valid origin X-Robots-Tag when Cloudflare is not the confirmed emitter.
  • Later response-header rules can override earlier changes, so verify the final rule order and response.
  • Robots.txt is a separate control point from this response-header directive — correct a Disallow rule using the generic-http-html guidance above.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: App Router metadata/generateMetadata, Pages Router next/head, or next.config headers()
 
Steps
  1. In the App Router, remove the unintended noindex from static metadata.robots or generateMetadata at the route that owns it.
  2. In the Pages Router, correct the owning next/head robots meta; for an X-Robots-Tag, correct the scoped next.config headers() rule.
  3. Deploy to the intended production environment and purge or bypass relevant caches before verification.
  
Verify on this platform
 
  • Inspect all final robots/googlebot meta and X-Robots-Tag values after redirects on the current production deployment.
 
Rollback
  1. Revert the route metadata, Head output, or headers() rule if the deployment exposes a route that should remain excluded.
 
Caveats
  • Vercel intentionally serves X-Robots-Tag: noindex for Preview Deployments and outdated Production Deployments; preserve that protection.
  • Do not diagnose an intentional preview response as a production metadata defect.
  • Robots.txt (a static file or a route handler such as app/robots.ts) is a separate control point from this metadata/header directive — correct a Disallow rule using the generic-http-html guidance above.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned publication, visibility, or response-header control
 
Steps
  1. Ask the vendor to identify the exact global or scoped control that emits noindex and remove it only for the confirmed public canonical URL.
  
Verify on this platform
 
  • Follow redirects and inspect all robots/googlebot meta and X-Robots-Tag values on the final public response, then use the Search Console live test.
 
Rollback
  1. Restore the vendor visibility control if an unintended page becomes public while the owning rule is corrected.
 
Caveats
  • Do not add index to compete with a noindex emitted elsewhere.
  • Keep the URL crawlable long enough for search engines to observe the removal.
  • Ask the vendor to confirm whether it also owns robots.txt for the domain — a Disallow rule there is a separate control point from a meta/header directive.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Follow redirects and confirm a crawlable 200 final response with no noindex in any robots/googlebot meta or X-Robots-Tag value.
  2. Confirm the canonical points to the intended URL and relevant caches no longer serve the directive.
  3. Fetch and parse robots.txt for the applicable user-agent group(s) and confirm the URL and its critical rendering resources are not disallowed.
  4. Rerun SEO Site Audit Crawler, On-Page SEO Checker, Google Index Checker, Render Gap, or Robots.txt Tester (whichever surfaced the finding), and use Search Console URL Inspection’s live test for Google’s current view.
 
Escalate when
 
Escalate when page ownership or publication intent is unclear, noindex or a robots.txt Disallow rule is applied by multiple layers, or removing it would expose private, duplicate, or staging content.
 
 
 
 
 
 
 
HTTP Header Checker · one finding
 
Multiple HTTP canonicals are present
 
Recommended action: Emit exactly one HTTP Link header with rel="canonical" for the preferred URL and remove conflicting canonical targets at the edge or origin.
 
Fix principle: Align every canonical signal for a page — the HTML <link rel=canonical>, an HTTP Link header, the post-render DOM, and each page's self-reference inside an hreflang cluster — on one confirmed intended URL; a conflict anywhere in that chain is resolved at its owning layer, never papered over by adding another canonical downstream.
 
 
 
 Implementation for your setup 
 
Confirm first: The page emits zero, more than one, or mutually disagreeing canonical signals across its HTML head, HTTP response header, or post-render DOM. A present canonical signal is relative, points to a URL that does not return a live 200 response, sits outside <head> where crawlers may not honor it, or only appears after client-side JavaScript runs.
 
Do not apply when: Exactly one absolute canonical URL is declared consistently across the HTML head, any HTTP header, and the rendered DOM, and that target itself returns 200. The apparent second reference is a distinct, valid annotation — an hreflang alternate, a pagination rel=next/prev, or another non-canonical link — not a competing canonical claim for the same page.
 
Likely control points: cms-app · server · edge-cdn
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Origin template, application server, or the layer that emits the HTTP Link header
 
Steps
  1. Enumerate every canonical signal for the URL — the HTML <link rel="canonical">, any HTTP Link: rel="canonical" response header, and the post-render DOM — and identify which layer emits each one.
  2. Choose exactly one intended absolute canonical URL per page and make every signal reproduce it verbatim; never declare a relative canonical, and never let a sitemap entry, redirect target, or hreflang alternate imply a different URL than the declared canonical.
  3. Correct or remove the emitting layer for any conflicting or duplicate signal at its source. Do not add a second, "corrective" canonical on top of an existing one.
  4. Confirm the canonical target itself returns a live 200 response on the protocol and host the site actually serves, not a redirect or error.
  
Verify on this platform
 
  • Fetch the raw response and inspect <head> for exactly one absolute canonical link, then check response headers for at most one agreeing Link: rel="canonical".
  • Confirm the canonical target itself returns 200 without redirecting, then use Search Console URL Inspection to compare the user-declared canonical against the Google-selected canonical.
 
Rollback
  1. Restore the previous canonical annotation or header if the correction points crawlers away from a URL that needs to stay indexed, then re-diagnose the true conflicting layer before trying again.
 
Caveats
  • A declared canonical is a hint, not a directive: Google may select a different URL as canonical for various reasons even when every signal you control agrees.
  • Don't specify different canonical URLs for the same page using different mechanisms (for example, one URL in a sitemap and a different one via rel=canonical) — the conflict itself is the defect, not the presence of any one mechanism.
  • If the page belongs to an hreflang cluster, each localized URL must canonicalize to itself (or its own best-language substitute), not to the primary-language version.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Theme output via the wp_head hook, or the single plugin/theme layer that has taken over the canonical tag
 
Steps
  1. Confirm WordPress core's native rel_canonical() output — hooked on wp_head — is the only source of the canonical tag, or that exactly one SEO plugin or theme has deliberately taken over that responsibility. Never leave two layers emitting a tag for the same page.
  2. If a plugin, theme, or manual template edit adds a second <link rel="canonical"> or a conflicting header, correct or remove it at that specific owning layer; do not add a third tag to compensate.
  3. Confirm the intended canonical target is the live, indexable URL the site actually wants, not a query-parameter, paginated, or otherwise non-canonical variant.
  
Verify on this platform
 
  • While logged out, view the public HTML source once and confirm a single <link rel="canonical"> matching the intended URL, then confirm no HTTP Link header contradicts it.
 
Rollback
  1. Restore the previous theme or plugin canonical configuration if removing a tag causes an unintended page to lose its canonical reference, then correct the true conflicting layer before trying again.
 
Caveats
  • Do not invent a specific SEO plugin's settings path: WordPress core exposes wp_get_canonical_url() and rel_canonical() on wp_head, but which plugin or theme, if any, has overridden that output is not verified here.
  • A page builder or headless WordPress frontend is owner-managed; use that system's own verified workflow instead of assuming core theme output controls the response.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: metadata.alternates.canonical / generateMetadata in the App Router, or next/head output in the Pages Router
 
Steps
  1. Set metadata.alternates.canonical (or the equivalent value returned from generateMetadata) to one absolute intended URL per App Router route; in the Pages Router, emit exactly one canonical <link> via next/head.
  2. Set metadataBase once at the root layout so relative canonical values resolve against the correct production host, instead of leaving canonical relative or inconsistent between preview and production domains.
  3. Do not also emit a second canonical tag from a component, a custom document, or an edge Proxy/Middleware response header once the metadata API owns the output.
  4. If the route belongs to an hreflang cluster, pair alternates.canonical with alternates.languages so each localized route canonicalizes to itself.
  
Verify on this platform
 
  • Fetch the deployed production route without executing JavaScript, confirm exactly one <link rel="canonical"> with the intended absolute URL, then rerun Canonicalization Checker or Render Gap on the same URL.
 
Rollback
  1. Revert the metadata export or route segment if the deployment changes the canonical for a route that needs to keep its prior target, then correct the actual conflicting layer before redeploying.
 
Caveats
  • metadataBase only fills in relative values; an already-absolute canonical value is used as-is and ignores metadataBase.
  • Confirm the production deployment domain matches the intended canonical host — a Preview Deployment URL is never the intended canonical target.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Online Store theme.liquid head output via the canonical_url Liquid object
 
Steps
  1. Duplicate the active theme and confirm theme.liquid emits exactly one <link rel="canonical" href="{{ canonical_url }}" /> in the head; Shopify's canonical_url object already resolves to the platform's intended canonical for standard product, collection, and content pages.
  2. If a second canonical tag is present — added by an app embed, a theme customization, or a duplicated snippet — remove it at that specific source rather than editing canonical_url itself.
  3. Preview representative product, collection, and content routes before publishing the corrected duplicate theme.
  
Verify on this platform
 
  • Inspect the published storefront response without browser execution and confirm a single canonical tag reflecting canonical_url on each route type.
 
Rollback
  1. Republish the previous theme if the corrected theme regresses canonical output or storefront functionality.
 
Caveats
  • These steps apply only to Shopify Online Store Liquid/JSON themes using the canonical_url object.
  • An app-owned storefront, a Hydrogen implementation, or an app that injects its own canonical tag is owner-managed; verify that system's own workflow rather than assuming theme.liquid is the only emitter.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned page builder, headless frontend, or hosted platform template
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer emits the canonical tag and header for the URL, then compare the user-declared and Google-selected canonical in Search Console URL Inspection.
  
Caveats
  • Escalate when the vendor cannot identify or expose the layer that emits a conflicting or duplicate canonical signal.
  • Do not accept a claim that the canonical is correct without one production-URL response showing a single agreeing signal.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch the raw response and confirm exactly one canonical signal (the HTML tag and, if present, the HTTP header) names the same absolute, live URL.
  2. Confirm the canonical target itself returns 200 without redirecting.
  3. Compare the user-declared canonical against Google's selected canonical in Search Console URL Inspection.
  4. Rerun the finding's originating tool (Canonicalization Checker, On-Page SEO Checker, SEO Site Audit Crawler, Render Gap, Google Index Checker, or HTTP Header Checker) on the same production URL.
 
Escalate when
 
Escalate when ownership of the emitting layer is unclear, more than one system claims to own the canonical output, or Google's selected canonical keeps diverging from the declared canonical after every signal you control has been made consistent.
 
 
 
 
 
 
 
HTTP Header Checker · one finding
 
HSTS is missing
 
Recommended action: Serve Strict-Transport-Security on HTTPS responses, starting with a tested max-age and expanding to includeSubDomains only when every subdomain is HTTPS-ready.
 
Fix principle: Start with exactly one HTTPS-only Strict-Transport-Security header using max-age=300, then stage 300 → 604800 → 2592000 → an intentional long value; do not default to includeSubDomains or preload.
 
 
 
 Implementation for your setup 
 
Confirm first: The final HTTPS response does not include Strict-Transport-Security. The hostname is intended to remain HTTPS-only and every hostname in the proposed scope works over HTTPS. HSTS is present but its max-age has stalled short of the value the rollout should have reached by now, leaving less durable protection than intended at this stage.
 
Do not apply when: A final edge or platform response already supplies HSTS, because adding another layer would duplicate ownership. Any hostname in the proposed scope still requires HTTP or has unresolved certificate, redirect, or mixed-content failures. The current max-age matches a deliberate, still-in-progress staging step (300 → 604800 → 2592000 → an intentional long value) rather than being stalled short of the intended target — a rollout genuinely in progress is not itself a defect.
 
Likely control points: server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The one origin or edge layer that owns the final HTTPS response
 
Steps
  1. Confirm all intended hosts work over HTTPS and remove any duplicate HSTS emitter.
  2. Emit exactly one Strict-Transport-Security header on HTTPS responses only, starting at max-age=300.
  3. Observe the full TTL, then stage 604800, 2592000, and finally an intentional long value.
  4. If HSTS is already present but its max-age has not advanced past an early stage for longer than that stage's own TTL, advance it to the next staged value rather than leaving it there indefinitely.
 
Configuration
Strict-Transport-Security: max-age=300
 
Verify on this platform
 
  • Inspect the final HTTPS response from a fresh client and count exactly one HSTS header.
  • Confirm the HTTP response does not emit HSTS and redirects cleanly to working HTTPS.
  • Confirm the current max-age is either the intended long-term value or a stage the rollout has not yet finished observing — not a value left unattended past its own TTL.
 
Rollback
  1. While HTTPS remains working, use the same owning response layer to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • Do not add includeSubDomains or preload during the baseline rollout.
  • HSTS is remembered by clients until the received max-age expires.
  • Advance only one staging step at a time; do not jump straight to a long max-age from a short one without observing the intermediate TTLs.
 
Official sources
 
 
Nginx
 
Status: supported · Location: The HTTPS server block or intended common HTTPS context
 
Steps
  1. Configure one HTTPS-only header with add_header and the always parameter; remove any duplicate upstream or edge emitter.
  2. Run nginx -t, then reload with nginx -s reload.
  3. Observe max-age=300 before staging 604800, 2592000, and an intentional long value.
 
Configuration
add_header Strict-Transport-Security "max-age=300" always;
 
Verify on this platform
 
  • Run nginx -t before reload.
  • Inspect normal and error HTTPS responses and confirm exactly one HSTS header is present.
 
Rollback
  1. While HTTPS remains working, use the same Nginx HTTPS context to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • A nested add_header directive changes inheritance; repeat the intended HSTS declaration in a child context when inheritance is broken.
  • Do not add includeSubDomains or preload during the baseline rollout.
 
Official sources
 
 
Apache
 
Status: supported · Location: The HTTPS virtual host response-header configuration
 
Steps
  1. Use mod_headers to set one HSTS header on HTTPS responses and remove any duplicate proxy or edge emitter.
  2. Run apachectl configtest, then apply with apachectl graceful.
  3. Observe max-age=300 before staging 604800, 2592000, and an intentional long value.
 
Configuration
Header always set Strict-Transport-Security "max-age=300"
 
Verify on this platform
 
  • Run apachectl configtest before the graceful reload.
  • Inspect final HTTPS success and error responses and confirm exactly one HSTS header is present.
 
Rollback
  1. While HTTPS remains working, use the same Apache HTTPS virtual host to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • Keep the directive out of HTTP-only virtual hosts.
  • Do not add includeSubDomains or preload during the baseline rollout.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Cloudflare dashboard → SSL/TLS → Edge Certificates → HTTP Strict Transport Security
 
Steps
  1. Make Cloudflare the single HSTS owner and remove duplicate origin or Worker emission.
  2. Because the dashboard minimum is one month, complete HTTPS readiness checks first and select the one-month max-age only when that commitment is acceptable.
  3. Leave includeSubDomains and preload disabled.
  
Verify on this platform
 
  • Inspect the final Cloudflare HTTPS response and confirm exactly one HSTS header with the selected one-month policy.
  • Confirm representative proxied hostnames remain available over HTTPS.
 
Rollback
  1. While HTTPS remains working, use the Cloudflare HSTS dashboard control to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • Cloudflare cannot provide the five-minute max-age=300 canary; do not represent its one-month minimum as equivalent.
  • Use one owning layer and do not enable includeSubDomains or preload by default.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: Branch by host: Vercel-managed response headers or self-hosted next.config headers()
 
Steps
  1. On Vercel, do not add another HSTS header: Vercel already platform-manages Strict-Transport-Security with max-age=63072000.
  2. For self-hosted Next.js only, use headers() on /:path* at the HTTPS response layer, ensure no proxy or edge duplicate exists, and start with max-age=300.
  3. For self-hosting, observe each TTL before staging 604800, 2592000, and an intentional long value.
 
Configuration
async headers() {
  return [{
    source: '/:path*',
    headers: [{ key: 'Strict-Transport-Security', value: 'max-age=300' }],
  }];
}
 
Verify on this platform
 
  • On Vercel, inspect the deployed response and confirm only the platform-managed header exists.
  • When self-hosted, inspect representative HTTPS routes and confirm exactly one header from the intended response layer.
 
Rollback
  1. While HTTPS remains working, use self-hosted Next.js headers(), or request the equivalent action from Vercel when the platform owns the policy to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • The snippet is for self-hosted Next.js, not a recommendation to duplicate Vercel’s managed max-age=63072000 policy.
  • Do not add includeSubDomains or preload during the baseline rollout.
 
Official sources
 
 
WordPress
 
Status: platform-managed · Location: Branch by host: WordPress.com platform policy or the self-hosted site’s host/server/edge
 
Steps
  1. On WordPress.com, rely on the platform-managed HTTPS/HSTS behavior and do not add a duplicate application-layer recipe.
  2. For self-hosted WordPress, configure the header at the actual host, web server, or edge using that platform’s verified instructions; do not invent a WordPress plugin implementation.
  3. Use the max-age=300 staged rollout only where the self-hosted response layer permits it.
  
Verify on this platform
 
  • Inspect the final public HTTPS response while logged out and confirm exactly one owning HSTS layer.
  • For self-hosted sites, verify the host/server/edge configuration rather than a WordPress admin-screen assumption.
 
Rollback
  1. While HTTPS remains working, use the WordPress.com support path or the actual self-hosted server/edge owner to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • WordPress.com is platform-managed.
  • Self-hosted WordPress does not make the CMS the correct header control point by itself; avoid unsourced plugin recipes.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: The vendor-controlled layer that owns the final HTTPS response
 
Steps
  1. Ask the vendor to identify whether it already emits HSTS and to guarantee one owning layer.
  2. Request max-age=300 first when supported; if the vendor enforces a larger minimum, treat that as a longer commitment and verify HTTPS readiness before enabling it.
  3. Keep includeSubDomains and preload disabled unless they are separately and intentionally approved.
  
Verify on this platform
 
  • Confirm the final public HTTPS response contains exactly one documented policy.
  • Obtain the vendor’s rollback procedure and minimum TTL before enabling the policy.
 
Rollback
  1. While HTTPS remains working, use the vendor control or support path to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • Do not layer a second header around a vendor-managed policy.
  • A vendor minimum above max-age=300 removes the short-canary safety window.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Inspect the final HTTPS response from a fresh client and confirm exactly one Strict-Transport-Security header.
  2. Confirm HSTS is emitted only over HTTPS.
  3. Observe each TTL before staging 300 → 604800 → 2592000 → an intentional long value.
  4. Test representative hostnames before separately considering includeSubDomains or preload.
  5. Rerun HTTP Header Checker.
 
Escalate when
 
Escalate before includeSubDomains, preload, or a long max-age when hostname ownership is distributed, legacy HTTP dependencies remain, the final header owner is uncertain, or the platform cannot provide a safe rollback path.
 
 
 
 
 
 
 
HTTP Header Checker · one finding
 
HSTS lifetime is short
 
Recommended action: Raise Strict-Transport-Security max-age to at least 31,536,000 seconds after confirming HTTPS works across the covered hosts.
 
Fix principle: Start with exactly one HTTPS-only Strict-Transport-Security header using max-age=300, then stage 300 → 604800 → 2592000 → an intentional long value; do not default to includeSubDomains or preload.
 
 
 
 Implementation for your setup 
 
Confirm first: The final HTTPS response does not include Strict-Transport-Security. The hostname is intended to remain HTTPS-only and every hostname in the proposed scope works over HTTPS. HSTS is present but its max-age has stalled short of the value the rollout should have reached by now, leaving less durable protection than intended at this stage.
 
Do not apply when: A final edge or platform response already supplies HSTS, because adding another layer would duplicate ownership. Any hostname in the proposed scope still requires HTTP or has unresolved certificate, redirect, or mixed-content failures. The current max-age matches a deliberate, still-in-progress staging step (300 → 604800 → 2592000 → an intentional long value) rather than being stalled short of the intended target — a rollout genuinely in progress is not itself a defect.
 
Likely control points: server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The one origin or edge layer that owns the final HTTPS response
 
Steps
  1. Confirm all intended hosts work over HTTPS and remove any duplicate HSTS emitter.
  2. Emit exactly one Strict-Transport-Security header on HTTPS responses only, starting at max-age=300.
  3. Observe the full TTL, then stage 604800, 2592000, and finally an intentional long value.
  4. If HSTS is already present but its max-age has not advanced past an early stage for longer than that stage's own TTL, advance it to the next staged value rather than leaving it there indefinitely.
 
Configuration
Strict-Transport-Security: max-age=300
 
Verify on this platform
 
  • Inspect the final HTTPS response from a fresh client and count exactly one HSTS header.
  • Confirm the HTTP response does not emit HSTS and redirects cleanly to working HTTPS.
  • Confirm the current max-age is either the intended long-term value or a stage the rollout has not yet finished observing — not a value left unattended past its own TTL.
 
Rollback
  1. While HTTPS remains working, use the same owning response layer to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • Do not add includeSubDomains or preload during the baseline rollout.
  • HSTS is remembered by clients until the received max-age expires.
  • Advance only one staging step at a time; do not jump straight to a long max-age from a short one without observing the intermediate TTLs.
 
Official sources
 
 
Nginx
 
Status: supported · Location: The HTTPS server block or intended common HTTPS context
 
Steps
  1. Configure one HTTPS-only header with add_header and the always parameter; remove any duplicate upstream or edge emitter.
  2. Run nginx -t, then reload with nginx -s reload.
  3. Observe max-age=300 before staging 604800, 2592000, and an intentional long value.
 
Configuration
add_header Strict-Transport-Security "max-age=300" always;
 
Verify on this platform
 
  • Run nginx -t before reload.
  • Inspect normal and error HTTPS responses and confirm exactly one HSTS header is present.
 
Rollback
  1. While HTTPS remains working, use the same Nginx HTTPS context to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • A nested add_header directive changes inheritance; repeat the intended HSTS declaration in a child context when inheritance is broken.
  • Do not add includeSubDomains or preload during the baseline rollout.
 
Official sources
 
 
Apache
 
Status: supported · Location: The HTTPS virtual host response-header configuration
 
Steps
  1. Use mod_headers to set one HSTS header on HTTPS responses and remove any duplicate proxy or edge emitter.
  2. Run apachectl configtest, then apply with apachectl graceful.
  3. Observe max-age=300 before staging 604800, 2592000, and an intentional long value.
 
Configuration
Header always set Strict-Transport-Security "max-age=300"
 
Verify on this platform
 
  • Run apachectl configtest before the graceful reload.
  • Inspect final HTTPS success and error responses and confirm exactly one HSTS header is present.
 
Rollback
  1. While HTTPS remains working, use the same Apache HTTPS virtual host to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • Keep the directive out of HTTP-only virtual hosts.
  • Do not add includeSubDomains or preload during the baseline rollout.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Cloudflare dashboard → SSL/TLS → Edge Certificates → HTTP Strict Transport Security
 
Steps
  1. Make Cloudflare the single HSTS owner and remove duplicate origin or Worker emission.
  2. Because the dashboard minimum is one month, complete HTTPS readiness checks first and select the one-month max-age only when that commitment is acceptable.
  3. Leave includeSubDomains and preload disabled.
  
Verify on this platform
 
  • Inspect the final Cloudflare HTTPS response and confirm exactly one HSTS header with the selected one-month policy.
  • Confirm representative proxied hostnames remain available over HTTPS.
 
Rollback
  1. While HTTPS remains working, use the Cloudflare HSTS dashboard control to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • Cloudflare cannot provide the five-minute max-age=300 canary; do not represent its one-month minimum as equivalent.
  • Use one owning layer and do not enable includeSubDomains or preload by default.
 
Official sources
 
 
Next.js / Vercel
 
Status: supported · Location: Branch by host: Vercel-managed response headers or self-hosted next.config headers()
 
Steps
  1. On Vercel, do not add another HSTS header: Vercel already platform-manages Strict-Transport-Security with max-age=63072000.
  2. For self-hosted Next.js only, use headers() on /:path* at the HTTPS response layer, ensure no proxy or edge duplicate exists, and start with max-age=300.
  3. For self-hosting, observe each TTL before staging 604800, 2592000, and an intentional long value.
 
Configuration
async headers() {
  return [{
    source: '/:path*',
    headers: [{ key: 'Strict-Transport-Security', value: 'max-age=300' }],
  }];
}
 
Verify on this platform
 
  • On Vercel, inspect the deployed response and confirm only the platform-managed header exists.
  • When self-hosted, inspect representative HTTPS routes and confirm exactly one header from the intended response layer.
 
Rollback
  1. While HTTPS remains working, use self-hosted Next.js headers(), or request the equivalent action from Vercel when the platform owns the policy to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • The snippet is for self-hosted Next.js, not a recommendation to duplicate Vercel’s managed max-age=63072000 policy.
  • Do not add includeSubDomains or preload during the baseline rollout.
 
Official sources
 
 
WordPress
 
Status: platform-managed · Location: Branch by host: WordPress.com platform policy or the self-hosted site’s host/server/edge
 
Steps
  1. On WordPress.com, rely on the platform-managed HTTPS/HSTS behavior and do not add a duplicate application-layer recipe.
  2. For self-hosted WordPress, configure the header at the actual host, web server, or edge using that platform’s verified instructions; do not invent a WordPress plugin implementation.
  3. Use the max-age=300 staged rollout only where the self-hosted response layer permits it.
  
Verify on this platform
 
  • Inspect the final public HTTPS response while logged out and confirm exactly one owning HSTS layer.
  • For self-hosted sites, verify the host/server/edge configuration rather than a WordPress admin-screen assumption.
 
Rollback
  1. While HTTPS remains working, use the WordPress.com support path or the actual self-hosted server/edge owner to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • WordPress.com is platform-managed.
  • Self-hosted WordPress does not make the CMS the correct header control point by itself; avoid unsourced plugin recipes.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: The vendor-controlled layer that owns the final HTTPS response
 
Steps
  1. Ask the vendor to identify whether it already emits HSTS and to guarantee one owning layer.
  2. Request max-age=300 first when supported; if the vendor enforces a larger minimum, treat that as a longer commitment and verify HTTPS readiness before enabling it.
  3. Keep includeSubDomains and preload disabled unless they are separately and intentionally approved.
  
Verify on this platform
 
  • Confirm the final public HTTPS response contains exactly one documented policy.
  • Obtain the vendor’s rollback procedure and minimum TTL before enabling the policy.
 
Rollback
  1. While HTTPS remains working, use the vendor control or support path to serve exactly one Strict-Transport-Security header with max-age=0.
  2. Verify the final HTTPS response contains exactly one HSTS header with max-age=0.
  3. Keep serving max-age=0 and wait through the prior max-age before removing the header entirely.
  4. If the domain is preloaded, complete the separate preload-removal process; browser removal can take 6–12 weeks or longer.
 
Caveats
  • Do not layer a second header around a vendor-managed policy.
  • A vendor minimum above max-age=300 removes the short-canary safety window.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Inspect the final HTTPS response from a fresh client and confirm exactly one Strict-Transport-Security header.
  2. Confirm HSTS is emitted only over HTTPS.
  3. Observe each TTL before staging 300 → 604800 → 2592000 → an intentional long value.
  4. Test representative hostnames before separately considering includeSubDomains or preload.
  5. Rerun HTTP Header Checker.
 
Escalate when
 
Escalate before includeSubDomains, preload, or a long max-age when hostname ownership is distributed, legacy HTTP dependencies remain, the final header owner is uncertain, or the platform cannot provide a safe rollback path.
 
 
 
 
 
 
 
HTTP Header Checker · one finding
 
Content Security Policy is missing
 
Recommended action: Add a Content-Security-Policy that allowlists the scripts, styles, images, frames, and connections the page actually needs, then tighten it from report-only to enforcement.
 
Fix principle: Diagnose which single layer owns the final HTTP response, then add each missing or unsafe protective header there — Content-Security-Policy staged through report-only before enforcement, framing protection, a safe Referrer-Policy, and correct Vary/Cache-Control behavior for crawler requests — without layering a second, conflicting policy on top of one already emitted upstream. These headers are a security and crawl-integrity fix; they are not an SEO ranking mechanism, and nothing here should be represented as one.
 
 
 
 Implementation for your setup 
 
Confirm first: The final HTTP response is missing Content-Security-Policy, missing framing protection (frame-ancestors or X-Frame-Options), or sends an unsafe Referrer-Policy (unsafe-url or origin-when-cross-origin) that leaks a full URL cross-origin. The response varies materially by User-Agent without a matching Vary declaration, or sends a no-store/private Cache-Control specifically to Googlebot on content that is genuinely public and not personalized.
 
Do not apply when: The header is already present at a layer upstream of the one being inspected (a CDN, WAF, or platform default), so adding it again would create a second, possibly conflicting, policy owner rather than fix a gap. The missing header is Strict-Transport-Security — HSTS has its own staged rollout and rollback procedure in the HSTS recipe; do not restart or duplicate that rollout here. The response is intentionally personalized or access-controlled, so a stricter caching or Vary declaration for that specific response is correct, not a defect.
 
Likely control points: server · edge-cdn · cms-app · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The single layer terminating the HTTP response — origin application, reverse proxy, or edge — for the hostname
 
Steps
  1. Identify the one layer that owns the final response headers for the hostname; confirm no upstream layer (CDN, WAF, load balancer) already sets a conflicting value before adding your own.
  2. Deploy Content-Security-Policy first as Content-Security-Policy-Report-Only with a policy that allowlists the scripts, styles, images, frames, and connections the page actually needs; monitor violation reports, then promote the identical policy to the enforcing header once nothing legitimate is being blocked.
  3. Add framing protection: `Content-Security-Policy: frame-ancestors 'self'` (or the specific origins allowed to embed the page, or `'none'` if embedding is never wanted), plus `X-Frame-Options` for older browsers that do not read frame-ancestors.
  4. Set `Referrer-Policy: strict-origin-when-cross-origin` (or a stricter policy the site's analytics still support) wherever `unsafe-url` or `origin-when-cross-origin` was previously sent.
  5. If the response legitimately varies by User-Agent, declare every varying request header in `Vary`; if it does not need to vary, stop sending a different representation by device or crawler class. Remove `no-store`/`private` Cache-Control specifically scoped to Googlebot unless that exact response is genuinely personalized, and return the same cacheable public representation other users receive.
  
Verify on this platform
 
  • Fetch the production response and confirm Content-Security-Policy, a framing-protection header, and a Referrer-Policy that is not unsafe-url/origin-when-cross-origin are each present exactly once from one owning layer.
  • Compare the response served to a standard browser User-Agent against the response served to Googlebot's user agent, and confirm the Vary header (if any) matches what actually varies and Cache-Control is not uniquely restrictive for the crawler.
  • Watch the Content-Security-Policy-Report-Only violation reports for at least one representative traffic cycle before promoting the policy to enforcement.
 
Rollback
  1. Revert to Content-Security-Policy-Report-Only (or remove the enforcing header entirely) if enforcement blocks legitimate functionality; restore the previous Referrer-Policy or Vary/Cache-Control value if the new one breaks an integration or a genuinely personalized response, then correct the specific allowlist or personalization boundary before re-enforcing.
 
Caveats
  • A CSP that goes straight to enforcement without a report-only period can break the site's own functionality; confirm zero blocking violations in report-only mode first.
  • frame-ancestors has no fallback to default-src and is not supported in a <meta> tag — it must be sent as a response header, alongside X-Frame-Options for legacy browser support.
  • Vary: * makes a response effectively uncacheable; declare only the specific request headers that actually change the response.
 
Official sources
 
 
WordPress
 
Status: supported · Location: A `wp_headers` filter callback in a plugin or must-use plugin; the host/server/edge layer if page caching bypasses PHP
 
Steps
  1. Add the missing headers via the `wp_headers` filter as a first attempt, following the same report-only-first rollout for Content-Security-Policy.
  2. If the site serves cached pages through a caching plugin or the host's page cache, `wp_headers` never runs for cached hits — configure the headers at the actual serving layer (host, reverse proxy, or edge) instead of assuming PHP-level control reaches every response.
  3. Confirm no host-level or CDN-level default already sets a conflicting header before adding your own.
  
Verify on this platform
 
  • Load the public page while logged out — matching how a cached visitor is served — and confirm the header is present on the response actually served, not only on an uncached admin preview.
  • Repeat the CSP report-only monitoring step before enforcing.
 
Rollback
  1. Remove the wp_headers callback or revert the host/edge configuration if a header change blocks site functionality or a legitimate embed, then correct the specific policy before reapplying.
 
Caveats
  • wp_headers cannot modify a response served entirely from a caching plugin's or host's cache; verify which layer actually serves the response before assuming a PHP filter is in effect.
  • Do not invent a specific security-headers plugin's settings screen; confirm which layer, if any, has already taken over header output before adding a duplicate.
 
Official sources
 
 
Shopify
 
Status: not-verified · Location: Shopify-managed response layer for Online Store (Liquid) themes; a Hydrogen storefront sets its own headers in application code
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • For an Online Store (Liquid) theme, ask Shopify support to confirm the current response-header baseline; no documented merchant-facing setting adds Content-Security-Policy, X-Frame-Options, or Referrer-Policy to a Liquid theme response, so treat that as unverified rather than inventing a settings path.
  • For a Hydrogen storefront, confirm the app explicitly builds and sets these headers in its own server entry (for example with createContentSecurityPolicy) on the response Headers object, and roll out a permissive policy before tightening it.
  
Caveats
  • No documented Online Store (Liquid) theme setting adds a custom response header; do not invent one. A Hydrogen custom storefront is the vendor-supported path that manages its own headers in application code.
  • Shopify's Hydrogen documentation for createContentSecurityPolicy does not describe a report-only mode; stage a deliberately permissive policy and tighten it in code rather than assuming a report-only header is available.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Cloudflare Rules → Transform Rules → Modify Response Header, applied in front of or alongside an origin fix
 
Steps
  1. Confirm no upstream origin layer already sets the header before adding an edge rule, to avoid two layers disagreeing on the same header value.
  2. Use a Response Header Transform Rule to set Content-Security-Policy, framing protection, and Referrer-Policy; headers prefixed cf- or x-cf-, and a small set of other reserved headers, cannot be modified this way.
  3. Roll out Content-Security-Policy as Content-Security-Policy-Report-Only at the edge first, then switch the rule to the enforcing header name once reports show no blocking violations.
  
Verify on this platform
 
  • Fetch the response through Cloudflare and confirm the intended header values, checking that no origin-set duplicate remains.
  • Confirm the CSP-Report-Only reports show no unexpected blocking before promoting to enforcement.
 
Rollback
  1. Disable or revert the Transform Rule if the edge-set header conflicts with an origin value or breaks the site, then correct the origin's own header before re-enabling the edge rule.
 
Caveats
  • Cloudflare documents a limited set of headers (including cf- and x-cf- prefixed headers, and other reserved headers) that Transform Rules cannot modify; confirm the specific header you need is not on that list before relying on it.
  • An edge-level header does not replace fixing the origin if the origin also disagrees — pick one owning layer.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned hosting or application platform
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer owns Content-Security-Policy, framing protection, Referrer-Policy, and Vary/Cache-Control behavior for crawler requests, and to roll out CSP as report-only before enforcing.
  • Independently fetch the production response and confirm the headers are present and not duplicated by a second layer.
  
Caveats
  • Escalate when the vendor cannot identify the owning layer or cannot provide a report-only rollout path for Content-Security-Policy.
  • Do not accept a vendor's claim that "headers are configured" without seeing them on a live production response.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch the final production response and confirm Content-Security-Policy, a framing-protection header, and a safe Referrer-Policy are each present exactly once from one owning layer.
  2. Confirm Content-Security-Policy was observed in Report-Only mode with no blocking violations before it was promoted to enforcement.
  3. Compare the response served to a standard browser User-Agent against the response served to Googlebot's user agent for Vary and Cache-Control differences.
  4. Rerun HTTP Header Checker (and Website Safety & Security Checker for the shared security-header-gap finding) on the same production URL.
 
Escalate when
 
Escalate when ownership of the response-header layer is unclear, more than one layer claims to set the same header, enforcing Content-Security-Policy would block functionality that cannot be resolved during the report-only period, or removing restrictive caching for Googlebot would expose genuinely personalized or access-controlled content.
 
 
 
 
 
 
 
HTTP Header Checker · one finding
 
Framing protection is missing
 
Recommended action: Set Content-Security-Policy frame-ancestors to the origins allowed to embed the page, or use X-Frame-Options: DENY when embedding is never allowed.
 
Fix principle: Diagnose which single layer owns the final HTTP response, then add each missing or unsafe protective header there — Content-Security-Policy staged through report-only before enforcement, framing protection, a safe Referrer-Policy, and correct Vary/Cache-Control behavior for crawler requests — without layering a second, conflicting policy on top of one already emitted upstream. These headers are a security and crawl-integrity fix; they are not an SEO ranking mechanism, and nothing here should be represented as one.
 
 
 
 Implementation for your setup 
 
Confirm first: The final HTTP response is missing Content-Security-Policy, missing framing protection (frame-ancestors or X-Frame-Options), or sends an unsafe Referrer-Policy (unsafe-url or origin-when-cross-origin) that leaks a full URL cross-origin. The response varies materially by User-Agent without a matching Vary declaration, or sends a no-store/private Cache-Control specifically to Googlebot on content that is genuinely public and not personalized.
 
Do not apply when: The header is already present at a layer upstream of the one being inspected (a CDN, WAF, or platform default), so adding it again would create a second, possibly conflicting, policy owner rather than fix a gap. The missing header is Strict-Transport-Security — HSTS has its own staged rollout and rollback procedure in the HSTS recipe; do not restart or duplicate that rollout here. The response is intentionally personalized or access-controlled, so a stricter caching or Vary declaration for that specific response is correct, not a defect.
 
Likely control points: server · edge-cdn · cms-app · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The single layer terminating the HTTP response — origin application, reverse proxy, or edge — for the hostname
 
Steps
  1. Identify the one layer that owns the final response headers for the hostname; confirm no upstream layer (CDN, WAF, load balancer) already sets a conflicting value before adding your own.
  2. Deploy Content-Security-Policy first as Content-Security-Policy-Report-Only with a policy that allowlists the scripts, styles, images, frames, and connections the page actually needs; monitor violation reports, then promote the identical policy to the enforcing header once nothing legitimate is being blocked.
  3. Add framing protection: `Content-Security-Policy: frame-ancestors 'self'` (or the specific origins allowed to embed the page, or `'none'` if embedding is never wanted), plus `X-Frame-Options` for older browsers that do not read frame-ancestors.
  4. Set `Referrer-Policy: strict-origin-when-cross-origin` (or a stricter policy the site's analytics still support) wherever `unsafe-url` or `origin-when-cross-origin` was previously sent.
  5. If the response legitimately varies by User-Agent, declare every varying request header in `Vary`; if it does not need to vary, stop sending a different representation by device or crawler class. Remove `no-store`/`private` Cache-Control specifically scoped to Googlebot unless that exact response is genuinely personalized, and return the same cacheable public representation other users receive.
  
Verify on this platform
 
  • Fetch the production response and confirm Content-Security-Policy, a framing-protection header, and a Referrer-Policy that is not unsafe-url/origin-when-cross-origin are each present exactly once from one owning layer.
  • Compare the response served to a standard browser User-Agent against the response served to Googlebot's user agent, and confirm the Vary header (if any) matches what actually varies and Cache-Control is not uniquely restrictive for the crawler.
  • Watch the Content-Security-Policy-Report-Only violation reports for at least one representative traffic cycle before promoting the policy to enforcement.
 
Rollback
  1. Revert to Content-Security-Policy-Report-Only (or remove the enforcing header entirely) if enforcement blocks legitimate functionality; restore the previous Referrer-Policy or Vary/Cache-Control value if the new one breaks an integration or a genuinely personalized response, then correct the specific allowlist or personalization boundary before re-enforcing.
 
Caveats
  • A CSP that goes straight to enforcement without a report-only period can break the site's own functionality; confirm zero blocking violations in report-only mode first.
  • frame-ancestors has no fallback to default-src and is not supported in a <meta> tag — it must be sent as a response header, alongside X-Frame-Options for legacy browser support.
  • Vary: * makes a response effectively uncacheable; declare only the specific request headers that actually change the response.
 
Official sources
 
 
WordPress
 
Status: supported · Location: A `wp_headers` filter callback in a plugin or must-use plugin; the host/server/edge layer if page caching bypasses PHP
 
Steps
  1. Add the missing headers via the `wp_headers` filter as a first attempt, following the same report-only-first rollout for Content-Security-Policy.
  2. If the site serves cached pages through a caching plugin or the host's page cache, `wp_headers` never runs for cached hits — configure the headers at the actual serving layer (host, reverse proxy, or edge) instead of assuming PHP-level control reaches every response.
  3. Confirm no host-level or CDN-level default already sets a conflicting header before adding your own.
  
Verify on this platform
 
  • Load the public page while logged out — matching how a cached visitor is served — and confirm the header is present on the response actually served, not only on an uncached admin preview.
  • Repeat the CSP report-only monitoring step before enforcing.
 
Rollback
  1. Remove the wp_headers callback or revert the host/edge configuration if a header change blocks site functionality or a legitimate embed, then correct the specific policy before reapplying.
 
Caveats
  • wp_headers cannot modify a response served entirely from a caching plugin's or host's cache; verify which layer actually serves the response before assuming a PHP filter is in effect.
  • Do not invent a specific security-headers plugin's settings screen; confirm which layer, if any, has already taken over header output before adding a duplicate.
 
Official sources
 
 
Shopify
 
Status: not-verified · Location: Shopify-managed response layer for Online Store (Liquid) themes; a Hydrogen storefront sets its own headers in application code
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • For an Online Store (Liquid) theme, ask Shopify support to confirm the current response-header baseline; no documented merchant-facing setting adds Content-Security-Policy, X-Frame-Options, or Referrer-Policy to a Liquid theme response, so treat that as unverified rather than inventing a settings path.
  • For a Hydrogen storefront, confirm the app explicitly builds and sets these headers in its own server entry (for example with createContentSecurityPolicy) on the response Headers object, and roll out a permissive policy before tightening it.
  
Caveats
  • No documented Online Store (Liquid) theme setting adds a custom response header; do not invent one. A Hydrogen custom storefront is the vendor-supported path that manages its own headers in application code.
  • Shopify's Hydrogen documentation for createContentSecurityPolicy does not describe a report-only mode; stage a deliberately permissive policy and tighten it in code rather than assuming a report-only header is available.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Cloudflare Rules → Transform Rules → Modify Response Header, applied in front of or alongside an origin fix
 
Steps
  1. Confirm no upstream origin layer already sets the header before adding an edge rule, to avoid two layers disagreeing on the same header value.
  2. Use a Response Header Transform Rule to set Content-Security-Policy, framing protection, and Referrer-Policy; headers prefixed cf- or x-cf-, and a small set of other reserved headers, cannot be modified this way.
  3. Roll out Content-Security-Policy as Content-Security-Policy-Report-Only at the edge first, then switch the rule to the enforcing header name once reports show no blocking violations.
  
Verify on this platform
 
  • Fetch the response through Cloudflare and confirm the intended header values, checking that no origin-set duplicate remains.
  • Confirm the CSP-Report-Only reports show no unexpected blocking before promoting to enforcement.
 
Rollback
  1. Disable or revert the Transform Rule if the edge-set header conflicts with an origin value or breaks the site, then correct the origin's own header before re-enabling the edge rule.
 
Caveats
  • Cloudflare documents a limited set of headers (including cf- and x-cf- prefixed headers, and other reserved headers) that Transform Rules cannot modify; confirm the specific header you need is not on that list before relying on it.
  • An edge-level header does not replace fixing the origin if the origin also disagrees — pick one owning layer.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned hosting or application platform
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer owns Content-Security-Policy, framing protection, Referrer-Policy, and Vary/Cache-Control behavior for crawler requests, and to roll out CSP as report-only before enforcing.
  • Independently fetch the production response and confirm the headers are present and not duplicated by a second layer.
  
Caveats
  • Escalate when the vendor cannot identify the owning layer or cannot provide a report-only rollout path for Content-Security-Policy.
  • Do not accept a vendor's claim that "headers are configured" without seeing them on a live production response.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch the final production response and confirm Content-Security-Policy, a framing-protection header, and a safe Referrer-Policy are each present exactly once from one owning layer.
  2. Confirm Content-Security-Policy was observed in Report-Only mode with no blocking violations before it was promoted to enforcement.
  3. Compare the response served to a standard browser User-Agent against the response served to Googlebot's user agent for Vary and Cache-Control differences.
  4. Rerun HTTP Header Checker (and Website Safety & Security Checker for the shared security-header-gap finding) on the same production URL.
 
Escalate when
 
Escalate when ownership of the response-header layer is unclear, more than one layer claims to set the same header, enforcing Content-Security-Policy would block functionality that cannot be resolved during the report-only period, or removing restrictive caching for Googlebot would expose genuinely personalized or access-controlled content.
 
 
 
 
 
 
 
HTTP Header Checker · one finding
 
Referrer policy leaks full URLs
 
Recommended action: Replace unsafe-url or origin-when-cross-origin with strict-origin-when-cross-origin so cross-origin requests do not expose full paths and query strings.
 
Fix principle: Diagnose which single layer owns the final HTTP response, then add each missing or unsafe protective header there — Content-Security-Policy staged through report-only before enforcement, framing protection, a safe Referrer-Policy, and correct Vary/Cache-Control behavior for crawler requests — without layering a second, conflicting policy on top of one already emitted upstream. These headers are a security and crawl-integrity fix; they are not an SEO ranking mechanism, and nothing here should be represented as one.
 
 
 
 Implementation for your setup 
 
Confirm first: The final HTTP response is missing Content-Security-Policy, missing framing protection (frame-ancestors or X-Frame-Options), or sends an unsafe Referrer-Policy (unsafe-url or origin-when-cross-origin) that leaks a full URL cross-origin. The response varies materially by User-Agent without a matching Vary declaration, or sends a no-store/private Cache-Control specifically to Googlebot on content that is genuinely public and not personalized.
 
Do not apply when: The header is already present at a layer upstream of the one being inspected (a CDN, WAF, or platform default), so adding it again would create a second, possibly conflicting, policy owner rather than fix a gap. The missing header is Strict-Transport-Security — HSTS has its own staged rollout and rollback procedure in the HSTS recipe; do not restart or duplicate that rollout here. The response is intentionally personalized or access-controlled, so a stricter caching or Vary declaration for that specific response is correct, not a defect.
 
Likely control points: server · edge-cdn · cms-app · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The single layer terminating the HTTP response — origin application, reverse proxy, or edge — for the hostname
 
Steps
  1. Identify the one layer that owns the final response headers for the hostname; confirm no upstream layer (CDN, WAF, load balancer) already sets a conflicting value before adding your own.
  2. Deploy Content-Security-Policy first as Content-Security-Policy-Report-Only with a policy that allowlists the scripts, styles, images, frames, and connections the page actually needs; monitor violation reports, then promote the identical policy to the enforcing header once nothing legitimate is being blocked.
  3. Add framing protection: `Content-Security-Policy: frame-ancestors 'self'` (or the specific origins allowed to embed the page, or `'none'` if embedding is never wanted), plus `X-Frame-Options` for older browsers that do not read frame-ancestors.
  4. Set `Referrer-Policy: strict-origin-when-cross-origin` (or a stricter policy the site's analytics still support) wherever `unsafe-url` or `origin-when-cross-origin` was previously sent.
  5. If the response legitimately varies by User-Agent, declare every varying request header in `Vary`; if it does not need to vary, stop sending a different representation by device or crawler class. Remove `no-store`/`private` Cache-Control specifically scoped to Googlebot unless that exact response is genuinely personalized, and return the same cacheable public representation other users receive.
  
Verify on this platform
 
  • Fetch the production response and confirm Content-Security-Policy, a framing-protection header, and a Referrer-Policy that is not unsafe-url/origin-when-cross-origin are each present exactly once from one owning layer.
  • Compare the response served to a standard browser User-Agent against the response served to Googlebot's user agent, and confirm the Vary header (if any) matches what actually varies and Cache-Control is not uniquely restrictive for the crawler.
  • Watch the Content-Security-Policy-Report-Only violation reports for at least one representative traffic cycle before promoting the policy to enforcement.
 
Rollback
  1. Revert to Content-Security-Policy-Report-Only (or remove the enforcing header entirely) if enforcement blocks legitimate functionality; restore the previous Referrer-Policy or Vary/Cache-Control value if the new one breaks an integration or a genuinely personalized response, then correct the specific allowlist or personalization boundary before re-enforcing.
 
Caveats
  • A CSP that goes straight to enforcement without a report-only period can break the site's own functionality; confirm zero blocking violations in report-only mode first.
  • frame-ancestors has no fallback to default-src and is not supported in a <meta> tag — it must be sent as a response header, alongside X-Frame-Options for legacy browser support.
  • Vary: * makes a response effectively uncacheable; declare only the specific request headers that actually change the response.
 
Official sources
 
 
WordPress
 
Status: supported · Location: A `wp_headers` filter callback in a plugin or must-use plugin; the host/server/edge layer if page caching bypasses PHP
 
Steps
  1. Add the missing headers via the `wp_headers` filter as a first attempt, following the same report-only-first rollout for Content-Security-Policy.
  2. If the site serves cached pages through a caching plugin or the host's page cache, `wp_headers` never runs for cached hits — configure the headers at the actual serving layer (host, reverse proxy, or edge) instead of assuming PHP-level control reaches every response.
  3. Confirm no host-level or CDN-level default already sets a conflicting header before adding your own.
  
Verify on this platform
 
  • Load the public page while logged out — matching how a cached visitor is served — and confirm the header is present on the response actually served, not only on an uncached admin preview.
  • Repeat the CSP report-only monitoring step before enforcing.
 
Rollback
  1. Remove the wp_headers callback or revert the host/edge configuration if a header change blocks site functionality or a legitimate embed, then correct the specific policy before reapplying.
 
Caveats
  • wp_headers cannot modify a response served entirely from a caching plugin's or host's cache; verify which layer actually serves the response before assuming a PHP filter is in effect.
  • Do not invent a specific security-headers plugin's settings screen; confirm which layer, if any, has already taken over header output before adding a duplicate.
 
Official sources
 
 
Shopify
 
Status: not-verified · Location: Shopify-managed response layer for Online Store (Liquid) themes; a Hydrogen storefront sets its own headers in application code
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • For an Online Store (Liquid) theme, ask Shopify support to confirm the current response-header baseline; no documented merchant-facing setting adds Content-Security-Policy, X-Frame-Options, or Referrer-Policy to a Liquid theme response, so treat that as unverified rather than inventing a settings path.
  • For a Hydrogen storefront, confirm the app explicitly builds and sets these headers in its own server entry (for example with createContentSecurityPolicy) on the response Headers object, and roll out a permissive policy before tightening it.
  
Caveats
  • No documented Online Store (Liquid) theme setting adds a custom response header; do not invent one. A Hydrogen custom storefront is the vendor-supported path that manages its own headers in application code.
  • Shopify's Hydrogen documentation for createContentSecurityPolicy does not describe a report-only mode; stage a deliberately permissive policy and tighten it in code rather than assuming a report-only header is available.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Cloudflare Rules → Transform Rules → Modify Response Header, applied in front of or alongside an origin fix
 
Steps
  1. Confirm no upstream origin layer already sets the header before adding an edge rule, to avoid two layers disagreeing on the same header value.
  2. Use a Response Header Transform Rule to set Content-Security-Policy, framing protection, and Referrer-Policy; headers prefixed cf- or x-cf-, and a small set of other reserved headers, cannot be modified this way.
  3. Roll out Content-Security-Policy as Content-Security-Policy-Report-Only at the edge first, then switch the rule to the enforcing header name once reports show no blocking violations.
  
Verify on this platform
 
  • Fetch the response through Cloudflare and confirm the intended header values, checking that no origin-set duplicate remains.
  • Confirm the CSP-Report-Only reports show no unexpected blocking before promoting to enforcement.
 
Rollback
  1. Disable or revert the Transform Rule if the edge-set header conflicts with an origin value or breaks the site, then correct the origin's own header before re-enabling the edge rule.
 
Caveats
  • Cloudflare documents a limited set of headers (including cf- and x-cf- prefixed headers, and other reserved headers) that Transform Rules cannot modify; confirm the specific header you need is not on that list before relying on it.
  • An edge-level header does not replace fixing the origin if the origin also disagrees — pick one owning layer.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned hosting or application platform
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer owns Content-Security-Policy, framing protection, Referrer-Policy, and Vary/Cache-Control behavior for crawler requests, and to roll out CSP as report-only before enforcing.
  • Independently fetch the production response and confirm the headers are present and not duplicated by a second layer.
  
Caveats
  • Escalate when the vendor cannot identify the owning layer or cannot provide a report-only rollout path for Content-Security-Policy.
  • Do not accept a vendor's claim that "headers are configured" without seeing them on a live production response.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch the final production response and confirm Content-Security-Policy, a framing-protection header, and a safe Referrer-Policy are each present exactly once from one owning layer.
  2. Confirm Content-Security-Policy was observed in Report-Only mode with no blocking violations before it was promoted to enforcement.
  3. Compare the response served to a standard browser User-Agent against the response served to Googlebot's user agent for Vary and Cache-Control differences.
  4. Rerun HTTP Header Checker (and Website Safety & Security Checker for the shared security-header-gap finding) on the same production URL.
 
Escalate when
 
Escalate when ownership of the response-header layer is unclear, more than one layer claims to set the same header, enforcing Content-Security-Policy would block functionality that cannot be resolved during the report-only period, or removing restrictive caching for Googlebot would expose genuinely personalized or access-controlled content.
 
 
 
 
 
 
 
HTTP Header Checker · one finding
 
Response varies by user agent
 
Recommended action: Stop varying the full response on User-Agent where possible; use feature detection or a narrowly normalized device signal and confirm crawlers receive equivalent primary content.
 
Fix principle: Diagnose which single layer owns the final HTTP response, then add each missing or unsafe protective header there — Content-Security-Policy staged through report-only before enforcement, framing protection, a safe Referrer-Policy, and correct Vary/Cache-Control behavior for crawler requests — without layering a second, conflicting policy on top of one already emitted upstream. These headers are a security and crawl-integrity fix; they are not an SEO ranking mechanism, and nothing here should be represented as one.
 
 
 
 Implementation for your setup 
 
Confirm first: The final HTTP response is missing Content-Security-Policy, missing framing protection (frame-ancestors or X-Frame-Options), or sends an unsafe Referrer-Policy (unsafe-url or origin-when-cross-origin) that leaks a full URL cross-origin. The response varies materially by User-Agent without a matching Vary declaration, or sends a no-store/private Cache-Control specifically to Googlebot on content that is genuinely public and not personalized.
 
Do not apply when: The header is already present at a layer upstream of the one being inspected (a CDN, WAF, or platform default), so adding it again would create a second, possibly conflicting, policy owner rather than fix a gap. The missing header is Strict-Transport-Security — HSTS has its own staged rollout and rollback procedure in the HSTS recipe; do not restart or duplicate that rollout here. The response is intentionally personalized or access-controlled, so a stricter caching or Vary declaration for that specific response is correct, not a defect.
 
Likely control points: server · edge-cdn · cms-app · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The single layer terminating the HTTP response — origin application, reverse proxy, or edge — for the hostname
 
Steps
  1. Identify the one layer that owns the final response headers for the hostname; confirm no upstream layer (CDN, WAF, load balancer) already sets a conflicting value before adding your own.
  2. Deploy Content-Security-Policy first as Content-Security-Policy-Report-Only with a policy that allowlists the scripts, styles, images, frames, and connections the page actually needs; monitor violation reports, then promote the identical policy to the enforcing header once nothing legitimate is being blocked.
  3. Add framing protection: `Content-Security-Policy: frame-ancestors 'self'` (or the specific origins allowed to embed the page, or `'none'` if embedding is never wanted), plus `X-Frame-Options` for older browsers that do not read frame-ancestors.
  4. Set `Referrer-Policy: strict-origin-when-cross-origin` (or a stricter policy the site's analytics still support) wherever `unsafe-url` or `origin-when-cross-origin` was previously sent.
  5. If the response legitimately varies by User-Agent, declare every varying request header in `Vary`; if it does not need to vary, stop sending a different representation by device or crawler class. Remove `no-store`/`private` Cache-Control specifically scoped to Googlebot unless that exact response is genuinely personalized, and return the same cacheable public representation other users receive.
  
Verify on this platform
 
  • Fetch the production response and confirm Content-Security-Policy, a framing-protection header, and a Referrer-Policy that is not unsafe-url/origin-when-cross-origin are each present exactly once from one owning layer.
  • Compare the response served to a standard browser User-Agent against the response served to Googlebot's user agent, and confirm the Vary header (if any) matches what actually varies and Cache-Control is not uniquely restrictive for the crawler.
  • Watch the Content-Security-Policy-Report-Only violation reports for at least one representative traffic cycle before promoting the policy to enforcement.
 
Rollback
  1. Revert to Content-Security-Policy-Report-Only (or remove the enforcing header entirely) if enforcement blocks legitimate functionality; restore the previous Referrer-Policy or Vary/Cache-Control value if the new one breaks an integration or a genuinely personalized response, then correct the specific allowlist or personalization boundary before re-enforcing.
 
Caveats
  • A CSP that goes straight to enforcement without a report-only period can break the site's own functionality; confirm zero blocking violations in report-only mode first.
  • frame-ancestors has no fallback to default-src and is not supported in a <meta> tag — it must be sent as a response header, alongside X-Frame-Options for legacy browser support.
  • Vary: * makes a response effectively uncacheable; declare only the specific request headers that actually change the response.
 
Official sources
 
 
WordPress
 
Status: supported · Location: A `wp_headers` filter callback in a plugin or must-use plugin; the host/server/edge layer if page caching bypasses PHP
 
Steps
  1. Add the missing headers via the `wp_headers` filter as a first attempt, following the same report-only-first rollout for Content-Security-Policy.
  2. If the site serves cached pages through a caching plugin or the host's page cache, `wp_headers` never runs for cached hits — configure the headers at the actual serving layer (host, reverse proxy, or edge) instead of assuming PHP-level control reaches every response.
  3. Confirm no host-level or CDN-level default already sets a conflicting header before adding your own.
  
Verify on this platform
 
  • Load the public page while logged out — matching how a cached visitor is served — and confirm the header is present on the response actually served, not only on an uncached admin preview.
  • Repeat the CSP report-only monitoring step before enforcing.
 
Rollback
  1. Remove the wp_headers callback or revert the host/edge configuration if a header change blocks site functionality or a legitimate embed, then correct the specific policy before reapplying.
 
Caveats
  • wp_headers cannot modify a response served entirely from a caching plugin's or host's cache; verify which layer actually serves the response before assuming a PHP filter is in effect.
  • Do not invent a specific security-headers plugin's settings screen; confirm which layer, if any, has already taken over header output before adding a duplicate.
 
Official sources
 
 
Shopify
 
Status: not-verified · Location: Shopify-managed response layer for Online Store (Liquid) themes; a Hydrogen storefront sets its own headers in application code
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • For an Online Store (Liquid) theme, ask Shopify support to confirm the current response-header baseline; no documented merchant-facing setting adds Content-Security-Policy, X-Frame-Options, or Referrer-Policy to a Liquid theme response, so treat that as unverified rather than inventing a settings path.
  • For a Hydrogen storefront, confirm the app explicitly builds and sets these headers in its own server entry (for example with createContentSecurityPolicy) on the response Headers object, and roll out a permissive policy before tightening it.
  
Caveats
  • No documented Online Store (Liquid) theme setting adds a custom response header; do not invent one. A Hydrogen custom storefront is the vendor-supported path that manages its own headers in application code.
  • Shopify's Hydrogen documentation for createContentSecurityPolicy does not describe a report-only mode; stage a deliberately permissive policy and tighten it in code rather than assuming a report-only header is available.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Cloudflare Rules → Transform Rules → Modify Response Header, applied in front of or alongside an origin fix
 
Steps
  1. Confirm no upstream origin layer already sets the header before adding an edge rule, to avoid two layers disagreeing on the same header value.
  2. Use a Response Header Transform Rule to set Content-Security-Policy, framing protection, and Referrer-Policy; headers prefixed cf- or x-cf-, and a small set of other reserved headers, cannot be modified this way.
  3. Roll out Content-Security-Policy as Content-Security-Policy-Report-Only at the edge first, then switch the rule to the enforcing header name once reports show no blocking violations.
  
Verify on this platform
 
  • Fetch the response through Cloudflare and confirm the intended header values, checking that no origin-set duplicate remains.
  • Confirm the CSP-Report-Only reports show no unexpected blocking before promoting to enforcement.
 
Rollback
  1. Disable or revert the Transform Rule if the edge-set header conflicts with an origin value or breaks the site, then correct the origin's own header before re-enabling the edge rule.
 
Caveats
  • Cloudflare documents a limited set of headers (including cf- and x-cf- prefixed headers, and other reserved headers) that Transform Rules cannot modify; confirm the specific header you need is not on that list before relying on it.
  • An edge-level header does not replace fixing the origin if the origin also disagrees — pick one owning layer.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned hosting or application platform
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer owns Content-Security-Policy, framing protection, Referrer-Policy, and Vary/Cache-Control behavior for crawler requests, and to roll out CSP as report-only before enforcing.
  • Independently fetch the production response and confirm the headers are present and not duplicated by a second layer.
  
Caveats
  • Escalate when the vendor cannot identify the owning layer or cannot provide a report-only rollout path for Content-Security-Policy.
  • Do not accept a vendor's claim that "headers are configured" without seeing them on a live production response.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch the final production response and confirm Content-Security-Policy, a framing-protection header, and a safe Referrer-Policy are each present exactly once from one owning layer.
  2. Confirm Content-Security-Policy was observed in Report-Only mode with no blocking violations before it was promoted to enforcement.
  3. Compare the response served to a standard browser User-Agent against the response served to Googlebot's user agent for Vary and Cache-Control differences.
  4. Rerun HTTP Header Checker (and Website Safety & Security Checker for the shared security-header-gap finding) on the same production URL.
 
Escalate when
 
Escalate when ownership of the response-header layer is unclear, more than one layer claims to set the same header, enforcing Content-Security-Policy would block functionality that cannot be resolved during the report-only period, or removing restrictive caching for Googlebot would expose genuinely personalized or access-controlled content.
 
 
 
 
 
 
 
HTTP Header Checker · one finding
 
Googlebot receives restrictive caching
 
Recommended action: Remove no-store/private caching sent specifically to Googlebot unless the content is genuinely personalized, and return the same cacheable public representation users receive.
 
Fix principle: Diagnose which single layer owns the final HTTP response, then add each missing or unsafe protective header there — Content-Security-Policy staged through report-only before enforcement, framing protection, a safe Referrer-Policy, and correct Vary/Cache-Control behavior for crawler requests — without layering a second, conflicting policy on top of one already emitted upstream. These headers are a security and crawl-integrity fix; they are not an SEO ranking mechanism, and nothing here should be represented as one.
 
 
 
 Implementation for your setup 
 
Confirm first: The final HTTP response is missing Content-Security-Policy, missing framing protection (frame-ancestors or X-Frame-Options), or sends an unsafe Referrer-Policy (unsafe-url or origin-when-cross-origin) that leaks a full URL cross-origin. The response varies materially by User-Agent without a matching Vary declaration, or sends a no-store/private Cache-Control specifically to Googlebot on content that is genuinely public and not personalized.
 
Do not apply when: The header is already present at a layer upstream of the one being inspected (a CDN, WAF, or platform default), so adding it again would create a second, possibly conflicting, policy owner rather than fix a gap. The missing header is Strict-Transport-Security — HSTS has its own staged rollout and rollback procedure in the HSTS recipe; do not restart or duplicate that rollout here. The response is intentionally personalized or access-controlled, so a stricter caching or Vary declaration for that specific response is correct, not a defect.
 
Likely control points: server · edge-cdn · cms-app · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: The single layer terminating the HTTP response — origin application, reverse proxy, or edge — for the hostname
 
Steps
  1. Identify the one layer that owns the final response headers for the hostname; confirm no upstream layer (CDN, WAF, load balancer) already sets a conflicting value before adding your own.
  2. Deploy Content-Security-Policy first as Content-Security-Policy-Report-Only with a policy that allowlists the scripts, styles, images, frames, and connections the page actually needs; monitor violation reports, then promote the identical policy to the enforcing header once nothing legitimate is being blocked.
  3. Add framing protection: `Content-Security-Policy: frame-ancestors 'self'` (or the specific origins allowed to embed the page, or `'none'` if embedding is never wanted), plus `X-Frame-Options` for older browsers that do not read frame-ancestors.
  4. Set `Referrer-Policy: strict-origin-when-cross-origin` (or a stricter policy the site's analytics still support) wherever `unsafe-url` or `origin-when-cross-origin` was previously sent.
  5. If the response legitimately varies by User-Agent, declare every varying request header in `Vary`; if it does not need to vary, stop sending a different representation by device or crawler class. Remove `no-store`/`private` Cache-Control specifically scoped to Googlebot unless that exact response is genuinely personalized, and return the same cacheable public representation other users receive.
  
Verify on this platform
 
  • Fetch the production response and confirm Content-Security-Policy, a framing-protection header, and a Referrer-Policy that is not unsafe-url/origin-when-cross-origin are each present exactly once from one owning layer.
  • Compare the response served to a standard browser User-Agent against the response served to Googlebot's user agent, and confirm the Vary header (if any) matches what actually varies and Cache-Control is not uniquely restrictive for the crawler.
  • Watch the Content-Security-Policy-Report-Only violation reports for at least one representative traffic cycle before promoting the policy to enforcement.
 
Rollback
  1. Revert to Content-Security-Policy-Report-Only (or remove the enforcing header entirely) if enforcement blocks legitimate functionality; restore the previous Referrer-Policy or Vary/Cache-Control value if the new one breaks an integration or a genuinely personalized response, then correct the specific allowlist or personalization boundary before re-enforcing.
 
Caveats
  • A CSP that goes straight to enforcement without a report-only period can break the site's own functionality; confirm zero blocking violations in report-only mode first.
  • frame-ancestors has no fallback to default-src and is not supported in a <meta> tag — it must be sent as a response header, alongside X-Frame-Options for legacy browser support.
  • Vary: * makes a response effectively uncacheable; declare only the specific request headers that actually change the response.
 
Official sources
 
 
WordPress
 
Status: supported · Location: A `wp_headers` filter callback in a plugin or must-use plugin; the host/server/edge layer if page caching bypasses PHP
 
Steps
  1. Add the missing headers via the `wp_headers` filter as a first attempt, following the same report-only-first rollout for Content-Security-Policy.
  2. If the site serves cached pages through a caching plugin or the host's page cache, `wp_headers` never runs for cached hits — configure the headers at the actual serving layer (host, reverse proxy, or edge) instead of assuming PHP-level control reaches every response.
  3. Confirm no host-level or CDN-level default already sets a conflicting header before adding your own.
  
Verify on this platform
 
  • Load the public page while logged out — matching how a cached visitor is served — and confirm the header is present on the response actually served, not only on an uncached admin preview.
  • Repeat the CSP report-only monitoring step before enforcing.
 
Rollback
  1. Remove the wp_headers callback or revert the host/edge configuration if a header change blocks site functionality or a legitimate embed, then correct the specific policy before reapplying.
 
Caveats
  • wp_headers cannot modify a response served entirely from a caching plugin's or host's cache; verify which layer actually serves the response before assuming a PHP filter is in effect.
  • Do not invent a specific security-headers plugin's settings screen; confirm which layer, if any, has already taken over header output before adding a duplicate.
 
Official sources
 
 
Shopify
 
Status: not-verified · Location: Shopify-managed response layer for Online Store (Liquid) themes; a Hydrogen storefront sets its own headers in application code
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • For an Online Store (Liquid) theme, ask Shopify support to confirm the current response-header baseline; no documented merchant-facing setting adds Content-Security-Policy, X-Frame-Options, or Referrer-Policy to a Liquid theme response, so treat that as unverified rather than inventing a settings path.
  • For a Hydrogen storefront, confirm the app explicitly builds and sets these headers in its own server entry (for example with createContentSecurityPolicy) on the response Headers object, and roll out a permissive policy before tightening it.
  
Caveats
  • No documented Online Store (Liquid) theme setting adds a custom response header; do not invent one. A Hydrogen custom storefront is the vendor-supported path that manages its own headers in application code.
  • Shopify's Hydrogen documentation for createContentSecurityPolicy does not describe a report-only mode; stage a deliberately permissive policy and tighten it in code rather than assuming a report-only header is available.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Cloudflare Rules → Transform Rules → Modify Response Header, applied in front of or alongside an origin fix
 
Steps
  1. Confirm no upstream origin layer already sets the header before adding an edge rule, to avoid two layers disagreeing on the same header value.
  2. Use a Response Header Transform Rule to set Content-Security-Policy, framing protection, and Referrer-Policy; headers prefixed cf- or x-cf-, and a small set of other reserved headers, cannot be modified this way.
  3. Roll out Content-Security-Policy as Content-Security-Policy-Report-Only at the edge first, then switch the rule to the enforcing header name once reports show no blocking violations.
  
Verify on this platform
 
  • Fetch the response through Cloudflare and confirm the intended header values, checking that no origin-set duplicate remains.
  • Confirm the CSP-Report-Only reports show no unexpected blocking before promoting to enforcement.
 
Rollback
  1. Disable or revert the Transform Rule if the edge-set header conflicts with an origin value or breaks the site, then correct the origin's own header before re-enabling the edge rule.
 
Caveats
  • Cloudflare documents a limited set of headers (including cf- and x-cf- prefixed headers, and other reserved headers) that Transform Rules cannot modify; confirm the specific header you need is not on that list before relying on it.
  • An edge-level header does not replace fixing the origin if the origin also disagrees — pick one owning layer.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned hosting or application platform
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm which single layer owns Content-Security-Policy, framing protection, Referrer-Policy, and Vary/Cache-Control behavior for crawler requests, and to roll out CSP as report-only before enforcing.
  • Independently fetch the production response and confirm the headers are present and not duplicated by a second layer.
  
Caveats
  • Escalate when the vendor cannot identify the owning layer or cannot provide a report-only rollout path for Content-Security-Policy.
  • Do not accept a vendor's claim that "headers are configured" without seeing them on a live production response.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Fetch the final production response and confirm Content-Security-Policy, a framing-protection header, and a safe Referrer-Policy are each present exactly once from one owning layer.
  2. Confirm Content-Security-Policy was observed in Report-Only mode with no blocking violations before it was promoted to enforcement.
  3. Compare the response served to a standard browser User-Agent against the response served to Googlebot's user agent for Vary and Cache-Control differences.
  4. Rerun HTTP Header Checker (and Website Safety & Security Checker for the shared security-header-gap finding) on the same production URL.
 
Escalate when
 
Escalate when ownership of the response-header layer is unclear, more than one layer claims to set the same header, enforcing Content-Security-Policy would block functionality that cannot be resolved during the report-only period, or removing restrictive caching for Googlebot would expose genuinely personalized or access-controlled content.
 
 
 
 
  
 
 
     
  •  Warnings Referrer-Policy is missing Fix: Set Referrer-Policy to strict-origin-when-cross-origin, or a stricter policy that still supports the site’s analytics requirements. 
  •  Information Cross-Origin Embedder Policy is missing Fix: If the page needs cross-origin isolation, set Cross-Origin-Embedder-Policy: require-corp and ensure every embedded cross-origin resource opts in; otherwise document that isolation is not required. 
  •  Errors Vary star prevents useful caching Fix: Replace Vary: * with only the request headers that actually change the response, such as Accept-Encoding or Accept-Language, so caches can reuse it. 
  •  Information Cache-Control is absent Fix: Set an explicit Cache-Control policy appropriate to the resource, using public max-age/s-maxage for reusable content or no-store for truly sensitive responses. 
  •  Information ETag is absent Fix: Add a stable ETag or Last-Modified validator for cacheable responses so clients can revalidate without downloading unchanged content. 
    •