Website Safety & Security Checker

Free, no signup. A practical security snapshot from public signals — useful for prioritizing fixes, never a penetration test.

Built by Patrick Stox

Checks run from our server; we fetch the URL you enter and don't keep the results. This fetches a public page and security.txt. The optional Google Web Risk component is a blocklist advisory, not a live malware scan. No certificate-expiry claim is made. 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 Website Safety 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 up to three URLs
Checks run sequentially and are not cached as a batch. Grades cover the same bounded public signals as the single check.
 
 
Sample report
Illustrative example — deterministic complete public-signal fixture
A
Safety snapshot: 100/100
HTTP 200 · TLS handshake succeeded.
  • Security headers: all scored header rules pass; COEP absence is informational only.
  • Mixed content: no HTTP subresources or insecure form actions in the supplied HTML.
  • security.txt: valid required fields found.
  • Web Risk: not configured, so no malware/blocklist verdict is claimed.
This perfect fixture is intentionally narrow: it demonstrates scoring and is not described as a secure real-world website.
 
 
 
How to use it
  1. Enter the exact public URL and choose Run safety check.
  2. Read the overall letter as a summary of the implemented checks, then inspect the security-header grade and every reason.
  3. Distinguish a configured Web Risk advisory from checks marked not configured or not evaluated.
  4. Validate and prioritize changes with the site's security owner; do not use this report as a penetration-test substitute.
 
 
 
     
     
     
What the results mean
  • A through F maps the numeric score into a summary band; it is not a risk certification.
  • Security header grade comes from explicit pass, warning, error, and informational header rules.
  • Issues to review lists every score reason plus security.txt and mixed-content evidence.
  • Not configured or not evaluated is unavailable evidence, never a clean Web Risk verdict.
 
How it works
The endpoint fetches the public page, selected response headers, security.txt, limited RDAP data, and an optional Google Web Risk advisory. Shared deterministic functions scan bounded raw HTML for insecure subresources and form actions and validate required security.txt fields; the browser grades the returned evidence and combines those bounded signals into a documented score.
 
Features
  • Security-header findings with exact remediation details.
  • Raw-HTML mixed-content and insecure-form checks.
  • security.txt validation and limited RDAP context.
  • Optional Google Web Risk advisory with unavailable states preserved.
  • Evidence-led score with explicit reasons.
  • Sequential comparison of up to three public URLs.
 
Limitations
This is not a penetration test, vulnerability scan, certificate inspector, privacy audit, or live malware analysis. It does not execute JavaScript or inspect every rendered resource, application route, dependency, account control, server port, or security practice. A high score only describes the fetched public signals.
 
Frequently asked questions
Does an A grade mean a website is safe?
No. It means the bounded public checks scored well. The tool does not test application vulnerabilities, authentication, server configuration, malware behavior, social engineering, or data handling.
What does a Google Web Risk result mean?
When configured, it checks whether Google Web Risk returns a matching blocklist advisory. No match is not a live malware scan or a guarantee that a page is harmless.
Why does security.txt affect the score?
A valid security.txt gives researchers a standard way to report vulnerabilities. It is a useful public trust and response-readiness signal, but it does not make the application itself secure.
Can this checker see an expired certificate?
No. It records whether the HTTPS connectionHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' completed, but the Worker interface does not expose certificate expiry, hostname coverage, chain, or cipher details.
What is mixed content?
Mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. occurs when an HTTPS page references an HTTP subresource or posts a form to HTTP. Those patterns can weaken transport protection and are detected only when visible in the fetched source.
 
Explore more
ToolDomain ReportToolHTTP Header CheckerToolDNS CheckerArticleSEO Due Diligence for M&AArticleSecurity Issues ReportArticleHTTPS for SEO
 
 
 
Feature requests for Website Safety 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
 
 
 
 
 
Website Safety & Security Checker · one finding
 
Page is not served over HTTPS
 
Recommended action: Serve the page and all canonical assets over HTTPS, then redirect HTTP requests directly to the HTTPS URL.
 
Fix principle: Every subresource, form action, and redirect destination a page emits must resolve to a live HTTPS URL served by a valid, unexpired certificate for that exact hostname; fix each insecure reference at the layer that emits it instead of suppressing the browser warning or leaving a redirect chain that dips back to HTTP.
 
 
 
 Implementation for your setup 
 
Confirm first: The page (or a required resource, form target, or redirect destination it emits) is reachable over plain HTTP, an HTTPS page loads an HTTP subresource, or a redirect chain lands on an insecure destination. The TLS certificate serving the hostname is expired, mismatched to the hostname, self-signed, or otherwise fails validation.
 
Do not apply when: Every resource, form action, and redirect destination for the page resolves to a live HTTPS URL, and the certificate serving that hostname is valid, unexpired, and issued for the exact hostname requested. The apparent HTTP reference is to a third-party resource the site does not control and that has no working HTTPS equivalent, not a first-party mixed-content or insecure-redirect 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: Origin template/application code for HTML, forms, and subresource URLs; the layer terminating TLS for the certificate; any layer emitting a redirect
 
Steps
  1. Enumerate every HTTP reference for the page: subresource URLs (scripts, styles, images, fonts, iframes), form action targets, and every hop of any redirect chain the page participates in — and identify the layer emitting each one.
  2. Replace each insecure reference with its live HTTPS equivalent (or a relative URL); do not merely rely on a browser or edge rewrite to mask the underlying defect.
  3. Confirm the TLS certificate serving the hostname is valid, unexpired, and issued for the exact hostname — no hostname mismatch and no self-signed chain a browser will reject.
  4. If any redirect exists for the page (HTTP-to-HTTPS or otherwise), confirm the destination and every intermediate hop are HTTPS end-to-end; never chain through an intermediate HTTP hop.
  
Verify on this platform
 
  • Load the page fresh (no cache) and confirm the browser console shows no mixed-content warnings; scripts, stylesheets, and iframes are blocked outright rather than silently upgraded, so check those specifically.
  • Trace the full redirect chain for the page and confirm every hop, including the final destination, is HTTPS.
  • Inspect the certificate presented for the hostname and confirm it is valid, unexpired, and matches the requested hostname.
 
Rollback
  1. If forcing HTTPS on one reference breaks a resource, form, or redirect that has no working HTTPS source yet, revert that single reference to its previous state while the underlying HTTPS gap is fixed, rather than leaving the page in a half-migrated state with an active browser warning.
 
Caveats
  • A `Content-Security-Policy: upgrade-insecure-requests` directive can upgrade legacy first-party subresource references as a stopgap, but it only rewrites non-navigational requests (not `<a href>` links or top-level navigation) and provides no fallback if the HTTPS destination is unavailable — it is not a substitute for fixing the true source.
  • Forcing an HTTPS redirect does not resolve mixed content by itself; the browser still evaluates the protocol of each embedded resource independently.
  • A resource on a third-party domain you do not control may have no HTTPS equivalent; document that limitation rather than leaving a silent redirect loop or a broken embed.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Settings → General (WordPress Address/Site Address); the theme, plugin, or stored content emitting the hard-coded HTTP reference; host/server/edge for the HTTP→HTTPS redirect
 
Steps
  1. Set both the WordPress Address and Site Address to the https:// URL once the certificate is installed and TLS works end-to-end for the hostname.
  2. Search stored content and theme/plugin output for hard-coded http:// references (images, embeds, form actions) and update them to https:// at their source rather than relying on the browser to silently fix them.
  3. Redirect the plain-HTTP host to HTTPS at the host, web server, or edge layer — not inside a page template — so every URL benefits, not only the ones WordPress itself renders.
  
Verify on this platform
 
  • View the public HTML source while logged out and confirm no remaining http:// references in scripts, styles, images, or form actions.
  • Confirm the WordPress Address and Site Address both read https:// and that a request to the plain-HTTP host redirects cleanly to HTTPS.
 
Rollback
  1. Restore the previous WordPress Address/Site Address values and any reverted template edit if switching to HTTPS breaks a login, asset path, or integration that depends on a hard-coded HTTP URL, then fix that specific integration before retrying.
 
Caveats
  • WordPress core does not rewrite historical post content for you; hard-coded http:// URLs saved in the database need a deliberate search-and-update, and a naive database find/replace can corrupt serialized data — use a tool built for that migration rather than raw SQL replace.
  • A page builder or headless WordPress frontend is owner-managed; verify that system's own HTTPS workflow rather than assuming Settings → General controls it.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify-managed TLS certificate (Settings → Domains); theme.liquid, section/snippet files, and app embeds for any hard-coded http:// reference
 
Steps
  1. Confirm the domain shows a Connected status with an active TLS certificate in Shopify admin — Shopify issues and auto-renews this certificate, and a third-party certificate cannot be substituted for it.
  2. Confirm plain-HTTP requests to the storefront redirect automatically to HTTPS; this is Shopify's default behavior once the certificate is issued, not a merchant-configured setting.
  3. Search theme.liquid, section/snippet files, and any app embed for a hard-coded http:// reference (an image, script, or form action) and correct it at that source — Shopify does not scan or rewrite theme code for you.
  
Verify on this platform
 
  • Confirm the domain status reads Connected with an active TLS certificate in Shopify admin.
  • Load representative storefront pages and confirm the browser reports no mixed-content warnings.
 
Rollback
  1. Revert the specific theme or app-embed edit if correcting a hard-coded reference breaks a storefront feature, then re-source that asset over HTTPS before reapplying.
 
Caveats
  • Standard Online Store (Liquid) themes have no merchant-facing control over the TLS certificate itself — treat certificate provisioning as platform-managed and escalate to Shopify support only if a domain stays stuck in a pending or unavailable TLS state.
  • This applies to Online Store Liquid themes; a Hydrogen custom storefront manages its own TLS and hosting outside Shopify's automatic certificate.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Cloudflare SSL/TLS → Edge Certificates, in front of the origin
 
Steps
  1. Set the SSL/TLS encryption mode to Full (strict) once the origin itself serves valid HTTPS, so the edge-to-origin hop is not silently downgraded to plain HTTP.
  2. Enable Always Use HTTPS to redirect HTTP requests at the edge; do not also run a duplicate redirect at the origin without confirming they agree — Cloudflare documents that combination as a source of redirect-loop errors.
  3. Enable Automatic HTTPS Rewrites as a stopgap for legacy first-party HTTP subresource references while the true source is corrected; it only rewrites resources it can confirm are available over HTTPS, and for third-party domains outside Cloudflare's known-HTTPS lists it rewrites active content only, not passive content like images.
  
Verify on this platform
 
  • Confirm the SSL/TLS encryption mode and Always Use HTTPS status in the Cloudflare dashboard.
  • Load the site through Cloudflare and confirm HTTP requests redirect to HTTPS with no redirect loop, then check for any remaining mixed-content console warnings that Automatic HTTPS Rewrites did not catch.
 
Rollback
  1. Disable Always Use HTTPS or revert the encryption mode if enabling it produces a redirect loop with an existing origin-level redirect, then remove the duplicate origin redirect before re-enabling.
 
Caveats
  • Automatic HTTPS Rewrites does not resolve every mixed-content case: resources injected by JavaScript or CSS after page load, and passive content from domains outside Cloudflare's known-HTTPS lists, still need a first-party fix.
  • Do not run an origin-level HTTP-to-HTTPS redirect at the same time as Always Use HTTPS without confirming they agree on the destination.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned hosting, page builder, or headless frontend
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm every subresource, form action, and redirect destination for the page resolves to HTTPS, and that the TLS certificate for the hostname is valid and renews automatically without manual intervention.
  • Independently load the page and confirm no mixed-content warnings and no HTTP hop anywhere in its redirect chain.
  
Caveats
  • Escalate when the vendor cannot confirm certificate renewal is automated, or cannot identify the source of a persistent HTTP reference.
  • Do not accept a claim of "HTTPS enabled" without seeing a live response that resolves every reference and redirect hop to HTTPS.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Load the production page fresh and confirm zero mixed-content warnings in the browser console.
  2. Trace the full redirect chain for the page and confirm every hop, including the final destination, is HTTPS.
  3. Inspect the TLS certificate served for the hostname and confirm it is valid, unexpired, and matches the hostname.
  4. Rerun Website Safety & Security Checker on the same production URL.
 
Escalate when
 
Escalate when certificate issuance or renewal is not automated and no owner is confirmed, a third-party resource has no working HTTPS equivalent, or a redirect must cross a hostname or vendor boundary you do not control.
 
 
 
 
 
 
 
Website Safety & Security Checker · one finding
 
HTTPS page loads an insecure resource
 
Recommended action: Replace every HTTP subresource with a working HTTPS URL or remove the insecure dependency.
 
Fix principle: Every subresource, form action, and redirect destination a page emits must resolve to a live HTTPS URL served by a valid, unexpired certificate for that exact hostname; fix each insecure reference at the layer that emits it instead of suppressing the browser warning or leaving a redirect chain that dips back to HTTP.
 
 
 
 Implementation for your setup 
 
Confirm first: The page (or a required resource, form target, or redirect destination it emits) is reachable over plain HTTP, an HTTPS page loads an HTTP subresource, or a redirect chain lands on an insecure destination. The TLS certificate serving the hostname is expired, mismatched to the hostname, self-signed, or otherwise fails validation.
 
Do not apply when: Every resource, form action, and redirect destination for the page resolves to a live HTTPS URL, and the certificate serving that hostname is valid, unexpired, and issued for the exact hostname requested. The apparent HTTP reference is to a third-party resource the site does not control and that has no working HTTPS equivalent, not a first-party mixed-content or insecure-redirect 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: Origin template/application code for HTML, forms, and subresource URLs; the layer terminating TLS for the certificate; any layer emitting a redirect
 
Steps
  1. Enumerate every HTTP reference for the page: subresource URLs (scripts, styles, images, fonts, iframes), form action targets, and every hop of any redirect chain the page participates in — and identify the layer emitting each one.
  2. Replace each insecure reference with its live HTTPS equivalent (or a relative URL); do not merely rely on a browser or edge rewrite to mask the underlying defect.
  3. Confirm the TLS certificate serving the hostname is valid, unexpired, and issued for the exact hostname — no hostname mismatch and no self-signed chain a browser will reject.
  4. If any redirect exists for the page (HTTP-to-HTTPS or otherwise), confirm the destination and every intermediate hop are HTTPS end-to-end; never chain through an intermediate HTTP hop.
  
Verify on this platform
 
  • Load the page fresh (no cache) and confirm the browser console shows no mixed-content warnings; scripts, stylesheets, and iframes are blocked outright rather than silently upgraded, so check those specifically.
  • Trace the full redirect chain for the page and confirm every hop, including the final destination, is HTTPS.
  • Inspect the certificate presented for the hostname and confirm it is valid, unexpired, and matches the requested hostname.
 
Rollback
  1. If forcing HTTPS on one reference breaks a resource, form, or redirect that has no working HTTPS source yet, revert that single reference to its previous state while the underlying HTTPS gap is fixed, rather than leaving the page in a half-migrated state with an active browser warning.
 
Caveats
  • A `Content-Security-Policy: upgrade-insecure-requests` directive can upgrade legacy first-party subresource references as a stopgap, but it only rewrites non-navigational requests (not `<a href>` links or top-level navigation) and provides no fallback if the HTTPS destination is unavailable — it is not a substitute for fixing the true source.
  • Forcing an HTTPS redirect does not resolve mixed content by itself; the browser still evaluates the protocol of each embedded resource independently.
  • A resource on a third-party domain you do not control may have no HTTPS equivalent; document that limitation rather than leaving a silent redirect loop or a broken embed.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Settings → General (WordPress Address/Site Address); the theme, plugin, or stored content emitting the hard-coded HTTP reference; host/server/edge for the HTTP→HTTPS redirect
 
Steps
  1. Set both the WordPress Address and Site Address to the https:// URL once the certificate is installed and TLS works end-to-end for the hostname.
  2. Search stored content and theme/plugin output for hard-coded http:// references (images, embeds, form actions) and update them to https:// at their source rather than relying on the browser to silently fix them.
  3. Redirect the plain-HTTP host to HTTPS at the host, web server, or edge layer — not inside a page template — so every URL benefits, not only the ones WordPress itself renders.
  
Verify on this platform
 
  • View the public HTML source while logged out and confirm no remaining http:// references in scripts, styles, images, or form actions.
  • Confirm the WordPress Address and Site Address both read https:// and that a request to the plain-HTTP host redirects cleanly to HTTPS.
 
Rollback
  1. Restore the previous WordPress Address/Site Address values and any reverted template edit if switching to HTTPS breaks a login, asset path, or integration that depends on a hard-coded HTTP URL, then fix that specific integration before retrying.
 
Caveats
  • WordPress core does not rewrite historical post content for you; hard-coded http:// URLs saved in the database need a deliberate search-and-update, and a naive database find/replace can corrupt serialized data — use a tool built for that migration rather than raw SQL replace.
  • A page builder or headless WordPress frontend is owner-managed; verify that system's own HTTPS workflow rather than assuming Settings → General controls it.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify-managed TLS certificate (Settings → Domains); theme.liquid, section/snippet files, and app embeds for any hard-coded http:// reference
 
Steps
  1. Confirm the domain shows a Connected status with an active TLS certificate in Shopify admin — Shopify issues and auto-renews this certificate, and a third-party certificate cannot be substituted for it.
  2. Confirm plain-HTTP requests to the storefront redirect automatically to HTTPS; this is Shopify's default behavior once the certificate is issued, not a merchant-configured setting.
  3. Search theme.liquid, section/snippet files, and any app embed for a hard-coded http:// reference (an image, script, or form action) and correct it at that source — Shopify does not scan or rewrite theme code for you.
  
Verify on this platform
 
  • Confirm the domain status reads Connected with an active TLS certificate in Shopify admin.
  • Load representative storefront pages and confirm the browser reports no mixed-content warnings.
 
Rollback
  1. Revert the specific theme or app-embed edit if correcting a hard-coded reference breaks a storefront feature, then re-source that asset over HTTPS before reapplying.
 
Caveats
  • Standard Online Store (Liquid) themes have no merchant-facing control over the TLS certificate itself — treat certificate provisioning as platform-managed and escalate to Shopify support only if a domain stays stuck in a pending or unavailable TLS state.
  • This applies to Online Store Liquid themes; a Hydrogen custom storefront manages its own TLS and hosting outside Shopify's automatic certificate.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Cloudflare SSL/TLS → Edge Certificates, in front of the origin
 
Steps
  1. Set the SSL/TLS encryption mode to Full (strict) once the origin itself serves valid HTTPS, so the edge-to-origin hop is not silently downgraded to plain HTTP.
  2. Enable Always Use HTTPS to redirect HTTP requests at the edge; do not also run a duplicate redirect at the origin without confirming they agree — Cloudflare documents that combination as a source of redirect-loop errors.
  3. Enable Automatic HTTPS Rewrites as a stopgap for legacy first-party HTTP subresource references while the true source is corrected; it only rewrites resources it can confirm are available over HTTPS, and for third-party domains outside Cloudflare's known-HTTPS lists it rewrites active content only, not passive content like images.
  
Verify on this platform
 
  • Confirm the SSL/TLS encryption mode and Always Use HTTPS status in the Cloudflare dashboard.
  • Load the site through Cloudflare and confirm HTTP requests redirect to HTTPS with no redirect loop, then check for any remaining mixed-content console warnings that Automatic HTTPS Rewrites did not catch.
 
Rollback
  1. Disable Always Use HTTPS or revert the encryption mode if enabling it produces a redirect loop with an existing origin-level redirect, then remove the duplicate origin redirect before re-enabling.
 
Caveats
  • Automatic HTTPS Rewrites does not resolve every mixed-content case: resources injected by JavaScript or CSS after page load, and passive content from domains outside Cloudflare's known-HTTPS lists, still need a first-party fix.
  • Do not run an origin-level HTTP-to-HTTPS redirect at the same time as Always Use HTTPS without confirming they agree on the destination.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned hosting, page builder, or headless frontend
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm every subresource, form action, and redirect destination for the page resolves to HTTPS, and that the TLS certificate for the hostname is valid and renews automatically without manual intervention.
  • Independently load the page and confirm no mixed-content warnings and no HTTP hop anywhere in its redirect chain.
  
Caveats
  • Escalate when the vendor cannot confirm certificate renewal is automated, or cannot identify the source of a persistent HTTP reference.
  • Do not accept a claim of "HTTPS enabled" without seeing a live response that resolves every reference and redirect hop to HTTPS.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Load the production page fresh and confirm zero mixed-content warnings in the browser console.
  2. Trace the full redirect chain for the page and confirm every hop, including the final destination, is HTTPS.
  3. Inspect the TLS certificate served for the hostname and confirm it is valid, unexpired, and matches the hostname.
  4. Rerun Website Safety & Security Checker on the same production URL.
 
Escalate when
 
Escalate when certificate issuance or renewal is not automated and no owner is confirmed, a third-party resource has no working HTTPS equivalent, or a redirect must cross a hostname or vendor boundary you do not control.
 
 
 
 
 
 
 
Website Safety & Security Checker · one finding
 
Form submits to an insecure URL
 
Recommended action: Change the form action to an HTTPS endpoint and confirm no redirect sends submitted data back over HTTP.
 
Fix principle: Every subresource, form action, and redirect destination a page emits must resolve to a live HTTPS URL served by a valid, unexpired certificate for that exact hostname; fix each insecure reference at the layer that emits it instead of suppressing the browser warning or leaving a redirect chain that dips back to HTTP.
 
 
 
 Implementation for your setup 
 
Confirm first: The page (or a required resource, form target, or redirect destination it emits) is reachable over plain HTTP, an HTTPS page loads an HTTP subresource, or a redirect chain lands on an insecure destination. The TLS certificate serving the hostname is expired, mismatched to the hostname, self-signed, or otherwise fails validation.
 
Do not apply when: Every resource, form action, and redirect destination for the page resolves to a live HTTPS URL, and the certificate serving that hostname is valid, unexpired, and issued for the exact hostname requested. The apparent HTTP reference is to a third-party resource the site does not control and that has no working HTTPS equivalent, not a first-party mixed-content or insecure-redirect 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: Origin template/application code for HTML, forms, and subresource URLs; the layer terminating TLS for the certificate; any layer emitting a redirect
 
Steps
  1. Enumerate every HTTP reference for the page: subresource URLs (scripts, styles, images, fonts, iframes), form action targets, and every hop of any redirect chain the page participates in — and identify the layer emitting each one.
  2. Replace each insecure reference with its live HTTPS equivalent (or a relative URL); do not merely rely on a browser or edge rewrite to mask the underlying defect.
  3. Confirm the TLS certificate serving the hostname is valid, unexpired, and issued for the exact hostname — no hostname mismatch and no self-signed chain a browser will reject.
  4. If any redirect exists for the page (HTTP-to-HTTPS or otherwise), confirm the destination and every intermediate hop are HTTPS end-to-end; never chain through an intermediate HTTP hop.
  
Verify on this platform
 
  • Load the page fresh (no cache) and confirm the browser console shows no mixed-content warnings; scripts, stylesheets, and iframes are blocked outright rather than silently upgraded, so check those specifically.
  • Trace the full redirect chain for the page and confirm every hop, including the final destination, is HTTPS.
  • Inspect the certificate presented for the hostname and confirm it is valid, unexpired, and matches the requested hostname.
 
Rollback
  1. If forcing HTTPS on one reference breaks a resource, form, or redirect that has no working HTTPS source yet, revert that single reference to its previous state while the underlying HTTPS gap is fixed, rather than leaving the page in a half-migrated state with an active browser warning.
 
Caveats
  • A `Content-Security-Policy: upgrade-insecure-requests` directive can upgrade legacy first-party subresource references as a stopgap, but it only rewrites non-navigational requests (not `<a href>` links or top-level navigation) and provides no fallback if the HTTPS destination is unavailable — it is not a substitute for fixing the true source.
  • Forcing an HTTPS redirect does not resolve mixed content by itself; the browser still evaluates the protocol of each embedded resource independently.
  • A resource on a third-party domain you do not control may have no HTTPS equivalent; document that limitation rather than leaving a silent redirect loop or a broken embed.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Settings → General (WordPress Address/Site Address); the theme, plugin, or stored content emitting the hard-coded HTTP reference; host/server/edge for the HTTP→HTTPS redirect
 
Steps
  1. Set both the WordPress Address and Site Address to the https:// URL once the certificate is installed and TLS works end-to-end for the hostname.
  2. Search stored content and theme/plugin output for hard-coded http:// references (images, embeds, form actions) and update them to https:// at their source rather than relying on the browser to silently fix them.
  3. Redirect the plain-HTTP host to HTTPS at the host, web server, or edge layer — not inside a page template — so every URL benefits, not only the ones WordPress itself renders.
  
Verify on this platform
 
  • View the public HTML source while logged out and confirm no remaining http:// references in scripts, styles, images, or form actions.
  • Confirm the WordPress Address and Site Address both read https:// and that a request to the plain-HTTP host redirects cleanly to HTTPS.
 
Rollback
  1. Restore the previous WordPress Address/Site Address values and any reverted template edit if switching to HTTPS breaks a login, asset path, or integration that depends on a hard-coded HTTP URL, then fix that specific integration before retrying.
 
Caveats
  • WordPress core does not rewrite historical post content for you; hard-coded http:// URLs saved in the database need a deliberate search-and-update, and a naive database find/replace can corrupt serialized data — use a tool built for that migration rather than raw SQL replace.
  • A page builder or headless WordPress frontend is owner-managed; verify that system's own HTTPS workflow rather than assuming Settings → General controls it.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify-managed TLS certificate (Settings → Domains); theme.liquid, section/snippet files, and app embeds for any hard-coded http:// reference
 
Steps
  1. Confirm the domain shows a Connected status with an active TLS certificate in Shopify admin — Shopify issues and auto-renews this certificate, and a third-party certificate cannot be substituted for it.
  2. Confirm plain-HTTP requests to the storefront redirect automatically to HTTPS; this is Shopify's default behavior once the certificate is issued, not a merchant-configured setting.
  3. Search theme.liquid, section/snippet files, and any app embed for a hard-coded http:// reference (an image, script, or form action) and correct it at that source — Shopify does not scan or rewrite theme code for you.
  
Verify on this platform
 
  • Confirm the domain status reads Connected with an active TLS certificate in Shopify admin.
  • Load representative storefront pages and confirm the browser reports no mixed-content warnings.
 
Rollback
  1. Revert the specific theme or app-embed edit if correcting a hard-coded reference breaks a storefront feature, then re-source that asset over HTTPS before reapplying.
 
Caveats
  • Standard Online Store (Liquid) themes have no merchant-facing control over the TLS certificate itself — treat certificate provisioning as platform-managed and escalate to Shopify support only if a domain stays stuck in a pending or unavailable TLS state.
  • This applies to Online Store Liquid themes; a Hydrogen custom storefront manages its own TLS and hosting outside Shopify's automatic certificate.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Cloudflare SSL/TLS → Edge Certificates, in front of the origin
 
Steps
  1. Set the SSL/TLS encryption mode to Full (strict) once the origin itself serves valid HTTPS, so the edge-to-origin hop is not silently downgraded to plain HTTP.
  2. Enable Always Use HTTPS to redirect HTTP requests at the edge; do not also run a duplicate redirect at the origin without confirming they agree — Cloudflare documents that combination as a source of redirect-loop errors.
  3. Enable Automatic HTTPS Rewrites as a stopgap for legacy first-party HTTP subresource references while the true source is corrected; it only rewrites resources it can confirm are available over HTTPS, and for third-party domains outside Cloudflare's known-HTTPS lists it rewrites active content only, not passive content like images.
  
Verify on this platform
 
  • Confirm the SSL/TLS encryption mode and Always Use HTTPS status in the Cloudflare dashboard.
  • Load the site through Cloudflare and confirm HTTP requests redirect to HTTPS with no redirect loop, then check for any remaining mixed-content console warnings that Automatic HTTPS Rewrites did not catch.
 
Rollback
  1. Disable Always Use HTTPS or revert the encryption mode if enabling it produces a redirect loop with an existing origin-level redirect, then remove the duplicate origin redirect before re-enabling.
 
Caveats
  • Automatic HTTPS Rewrites does not resolve every mixed-content case: resources injected by JavaScript or CSS after page load, and passive content from domains outside Cloudflare's known-HTTPS lists, still need a first-party fix.
  • Do not run an origin-level HTTP-to-HTTPS redirect at the same time as Always Use HTTPS without confirming they agree on the destination.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned hosting, page builder, or headless frontend
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm every subresource, form action, and redirect destination for the page resolves to HTTPS, and that the TLS certificate for the hostname is valid and renews automatically without manual intervention.
  • Independently load the page and confirm no mixed-content warnings and no HTTP hop anywhere in its redirect chain.
  
Caveats
  • Escalate when the vendor cannot confirm certificate renewal is automated, or cannot identify the source of a persistent HTTP reference.
  • Do not accept a claim of "HTTPS enabled" without seeing a live response that resolves every reference and redirect hop to HTTPS.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Load the production page fresh and confirm zero mixed-content warnings in the browser console.
  2. Trace the full redirect chain for the page and confirm every hop, including the final destination, is HTTPS.
  3. Inspect the TLS certificate served for the hostname and confirm it is valid, unexpired, and matches the hostname.
  4. Rerun Website Safety & Security Checker on the same production URL.
 
Escalate when
 
Escalate when certificate issuance or renewal is not automated and no owner is confirmed, a third-party resource has no working HTTPS equivalent, or a redirect must cross a hostname or vendor boundary you do not control.
 
 
 
 
 
 
 
Website Safety & Security Checker · one finding
 
TLS certificate signal needs attention
 
Recommended action: Repair or renew the certificate and TLS chain, then confirm the HTTPS handshake succeeds.
 
Fix principle: Every subresource, form action, and redirect destination a page emits must resolve to a live HTTPS URL served by a valid, unexpired certificate for that exact hostname; fix each insecure reference at the layer that emits it instead of suppressing the browser warning or leaving a redirect chain that dips back to HTTP.
 
 
 
 Implementation for your setup 
 
Confirm first: The page (or a required resource, form target, or redirect destination it emits) is reachable over plain HTTP, an HTTPS page loads an HTTP subresource, or a redirect chain lands on an insecure destination. The TLS certificate serving the hostname is expired, mismatched to the hostname, self-signed, or otherwise fails validation.
 
Do not apply when: Every resource, form action, and redirect destination for the page resolves to a live HTTPS URL, and the certificate serving that hostname is valid, unexpired, and issued for the exact hostname requested. The apparent HTTP reference is to a third-party resource the site does not control and that has no working HTTPS equivalent, not a first-party mixed-content or insecure-redirect 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: Origin template/application code for HTML, forms, and subresource URLs; the layer terminating TLS for the certificate; any layer emitting a redirect
 
Steps
  1. Enumerate every HTTP reference for the page: subresource URLs (scripts, styles, images, fonts, iframes), form action targets, and every hop of any redirect chain the page participates in — and identify the layer emitting each one.
  2. Replace each insecure reference with its live HTTPS equivalent (or a relative URL); do not merely rely on a browser or edge rewrite to mask the underlying defect.
  3. Confirm the TLS certificate serving the hostname is valid, unexpired, and issued for the exact hostname — no hostname mismatch and no self-signed chain a browser will reject.
  4. If any redirect exists for the page (HTTP-to-HTTPS or otherwise), confirm the destination and every intermediate hop are HTTPS end-to-end; never chain through an intermediate HTTP hop.
  
Verify on this platform
 
  • Load the page fresh (no cache) and confirm the browser console shows no mixed-content warnings; scripts, stylesheets, and iframes are blocked outright rather than silently upgraded, so check those specifically.
  • Trace the full redirect chain for the page and confirm every hop, including the final destination, is HTTPS.
  • Inspect the certificate presented for the hostname and confirm it is valid, unexpired, and matches the requested hostname.
 
Rollback
  1. If forcing HTTPS on one reference breaks a resource, form, or redirect that has no working HTTPS source yet, revert that single reference to its previous state while the underlying HTTPS gap is fixed, rather than leaving the page in a half-migrated state with an active browser warning.
 
Caveats
  • A `Content-Security-Policy: upgrade-insecure-requests` directive can upgrade legacy first-party subresource references as a stopgap, but it only rewrites non-navigational requests (not `<a href>` links or top-level navigation) and provides no fallback if the HTTPS destination is unavailable — it is not a substitute for fixing the true source.
  • Forcing an HTTPS redirect does not resolve mixed content by itself; the browser still evaluates the protocol of each embedded resource independently.
  • A resource on a third-party domain you do not control may have no HTTPS equivalent; document that limitation rather than leaving a silent redirect loop or a broken embed.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Settings → General (WordPress Address/Site Address); the theme, plugin, or stored content emitting the hard-coded HTTP reference; host/server/edge for the HTTP→HTTPS redirect
 
Steps
  1. Set both the WordPress Address and Site Address to the https:// URL once the certificate is installed and TLS works end-to-end for the hostname.
  2. Search stored content and theme/plugin output for hard-coded http:// references (images, embeds, form actions) and update them to https:// at their source rather than relying on the browser to silently fix them.
  3. Redirect the plain-HTTP host to HTTPS at the host, web server, or edge layer — not inside a page template — so every URL benefits, not only the ones WordPress itself renders.
  
Verify on this platform
 
  • View the public HTML source while logged out and confirm no remaining http:// references in scripts, styles, images, or form actions.
  • Confirm the WordPress Address and Site Address both read https:// and that a request to the plain-HTTP host redirects cleanly to HTTPS.
 
Rollback
  1. Restore the previous WordPress Address/Site Address values and any reverted template edit if switching to HTTPS breaks a login, asset path, or integration that depends on a hard-coded HTTP URL, then fix that specific integration before retrying.
 
Caveats
  • WordPress core does not rewrite historical post content for you; hard-coded http:// URLs saved in the database need a deliberate search-and-update, and a naive database find/replace can corrupt serialized data — use a tool built for that migration rather than raw SQL replace.
  • A page builder or headless WordPress frontend is owner-managed; verify that system's own HTTPS workflow rather than assuming Settings → General controls it.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify-managed TLS certificate (Settings → Domains); theme.liquid, section/snippet files, and app embeds for any hard-coded http:// reference
 
Steps
  1. Confirm the domain shows a Connected status with an active TLS certificate in Shopify admin — Shopify issues and auto-renews this certificate, and a third-party certificate cannot be substituted for it.
  2. Confirm plain-HTTP requests to the storefront redirect automatically to HTTPS; this is Shopify's default behavior once the certificate is issued, not a merchant-configured setting.
  3. Search theme.liquid, section/snippet files, and any app embed for a hard-coded http:// reference (an image, script, or form action) and correct it at that source — Shopify does not scan or rewrite theme code for you.
  
Verify on this platform
 
  • Confirm the domain status reads Connected with an active TLS certificate in Shopify admin.
  • Load representative storefront pages and confirm the browser reports no mixed-content warnings.
 
Rollback
  1. Revert the specific theme or app-embed edit if correcting a hard-coded reference breaks a storefront feature, then re-source that asset over HTTPS before reapplying.
 
Caveats
  • Standard Online Store (Liquid) themes have no merchant-facing control over the TLS certificate itself — treat certificate provisioning as platform-managed and escalate to Shopify support only if a domain stays stuck in a pending or unavailable TLS state.
  • This applies to Online Store Liquid themes; a Hydrogen custom storefront manages its own TLS and hosting outside Shopify's automatic certificate.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Cloudflare SSL/TLS → Edge Certificates, in front of the origin
 
Steps
  1. Set the SSL/TLS encryption mode to Full (strict) once the origin itself serves valid HTTPS, so the edge-to-origin hop is not silently downgraded to plain HTTP.
  2. Enable Always Use HTTPS to redirect HTTP requests at the edge; do not also run a duplicate redirect at the origin without confirming they agree — Cloudflare documents that combination as a source of redirect-loop errors.
  3. Enable Automatic HTTPS Rewrites as a stopgap for legacy first-party HTTP subresource references while the true source is corrected; it only rewrites resources it can confirm are available over HTTPS, and for third-party domains outside Cloudflare's known-HTTPS lists it rewrites active content only, not passive content like images.
  
Verify on this platform
 
  • Confirm the SSL/TLS encryption mode and Always Use HTTPS status in the Cloudflare dashboard.
  • Load the site through Cloudflare and confirm HTTP requests redirect to HTTPS with no redirect loop, then check for any remaining mixed-content console warnings that Automatic HTTPS Rewrites did not catch.
 
Rollback
  1. Disable Always Use HTTPS or revert the encryption mode if enabling it produces a redirect loop with an existing origin-level redirect, then remove the duplicate origin redirect before re-enabling.
 
Caveats
  • Automatic HTTPS Rewrites does not resolve every mixed-content case: resources injected by JavaScript or CSS after page load, and passive content from domains outside Cloudflare's known-HTTPS lists, still need a first-party fix.
  • Do not run an origin-level HTTP-to-HTTPS redirect at the same time as Always Use HTTPS without confirming they agree on the destination.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned hosting, page builder, or headless frontend
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm every subresource, form action, and redirect destination for the page resolves to HTTPS, and that the TLS certificate for the hostname is valid and renews automatically without manual intervention.
  • Independently load the page and confirm no mixed-content warnings and no HTTP hop anywhere in its redirect chain.
  
Caveats
  • Escalate when the vendor cannot confirm certificate renewal is automated, or cannot identify the source of a persistent HTTP reference.
  • Do not accept a claim of "HTTPS enabled" without seeing a live response that resolves every reference and redirect hop to HTTPS.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Load the production page fresh and confirm zero mixed-content warnings in the browser console.
  2. Trace the full redirect chain for the page and confirm every hop, including the final destination, is HTTPS.
  3. Inspect the TLS certificate served for the hostname and confirm it is valid, unexpired, and matches the hostname.
  4. Rerun Website Safety & Security Checker on the same production URL.
 
Escalate when
 
Escalate when certificate issuance or renewal is not automated and no owner is confirmed, a third-party resource has no working HTTPS equivalent, or a redirect must cross a hostname or vendor boundary you do not control.
 
 
 
 
 
 
 
Website Safety & Security Checker · one finding
 
Safe URL redirects to an insecure destination
 
Recommended action: Keep every redirect hop and the final destination on HTTPS.
 
Fix principle: Every subresource, form action, and redirect destination a page emits must resolve to a live HTTPS URL served by a valid, unexpired certificate for that exact hostname; fix each insecure reference at the layer that emits it instead of suppressing the browser warning or leaving a redirect chain that dips back to HTTP.
 
 
 
 Implementation for your setup 
 
Confirm first: The page (or a required resource, form target, or redirect destination it emits) is reachable over plain HTTP, an HTTPS page loads an HTTP subresource, or a redirect chain lands on an insecure destination. The TLS certificate serving the hostname is expired, mismatched to the hostname, self-signed, or otherwise fails validation.
 
Do not apply when: Every resource, form action, and redirect destination for the page resolves to a live HTTPS URL, and the certificate serving that hostname is valid, unexpired, and issued for the exact hostname requested. The apparent HTTP reference is to a third-party resource the site does not control and that has no working HTTPS equivalent, not a first-party mixed-content or insecure-redirect 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: Origin template/application code for HTML, forms, and subresource URLs; the layer terminating TLS for the certificate; any layer emitting a redirect
 
Steps
  1. Enumerate every HTTP reference for the page: subresource URLs (scripts, styles, images, fonts, iframes), form action targets, and every hop of any redirect chain the page participates in — and identify the layer emitting each one.
  2. Replace each insecure reference with its live HTTPS equivalent (or a relative URL); do not merely rely on a browser or edge rewrite to mask the underlying defect.
  3. Confirm the TLS certificate serving the hostname is valid, unexpired, and issued for the exact hostname — no hostname mismatch and no self-signed chain a browser will reject.
  4. If any redirect exists for the page (HTTP-to-HTTPS or otherwise), confirm the destination and every intermediate hop are HTTPS end-to-end; never chain through an intermediate HTTP hop.
  
Verify on this platform
 
  • Load the page fresh (no cache) and confirm the browser console shows no mixed-content warnings; scripts, stylesheets, and iframes are blocked outright rather than silently upgraded, so check those specifically.
  • Trace the full redirect chain for the page and confirm every hop, including the final destination, is HTTPS.
  • Inspect the certificate presented for the hostname and confirm it is valid, unexpired, and matches the requested hostname.
 
Rollback
  1. If forcing HTTPS on one reference breaks a resource, form, or redirect that has no working HTTPS source yet, revert that single reference to its previous state while the underlying HTTPS gap is fixed, rather than leaving the page in a half-migrated state with an active browser warning.
 
Caveats
  • A `Content-Security-Policy: upgrade-insecure-requests` directive can upgrade legacy first-party subresource references as a stopgap, but it only rewrites non-navigational requests (not `<a href>` links or top-level navigation) and provides no fallback if the HTTPS destination is unavailable — it is not a substitute for fixing the true source.
  • Forcing an HTTPS redirect does not resolve mixed content by itself; the browser still evaluates the protocol of each embedded resource independently.
  • A resource on a third-party domain you do not control may have no HTTPS equivalent; document that limitation rather than leaving a silent redirect loop or a broken embed.
 
Official sources
 
 
WordPress
 
Status: supported · Location: Settings → General (WordPress Address/Site Address); the theme, plugin, or stored content emitting the hard-coded HTTP reference; host/server/edge for the HTTP→HTTPS redirect
 
Steps
  1. Set both the WordPress Address and Site Address to the https:// URL once the certificate is installed and TLS works end-to-end for the hostname.
  2. Search stored content and theme/plugin output for hard-coded http:// references (images, embeds, form actions) and update them to https:// at their source rather than relying on the browser to silently fix them.
  3. Redirect the plain-HTTP host to HTTPS at the host, web server, or edge layer — not inside a page template — so every URL benefits, not only the ones WordPress itself renders.
  
Verify on this platform
 
  • View the public HTML source while logged out and confirm no remaining http:// references in scripts, styles, images, or form actions.
  • Confirm the WordPress Address and Site Address both read https:// and that a request to the plain-HTTP host redirects cleanly to HTTPS.
 
Rollback
  1. Restore the previous WordPress Address/Site Address values and any reverted template edit if switching to HTTPS breaks a login, asset path, or integration that depends on a hard-coded HTTP URL, then fix that specific integration before retrying.
 
Caveats
  • WordPress core does not rewrite historical post content for you; hard-coded http:// URLs saved in the database need a deliberate search-and-update, and a naive database find/replace can corrupt serialized data — use a tool built for that migration rather than raw SQL replace.
  • A page builder or headless WordPress frontend is owner-managed; verify that system's own HTTPS workflow rather than assuming Settings → General controls it.
 
Official sources
 
 
Shopify
 
Status: supported · Location: Shopify-managed TLS certificate (Settings → Domains); theme.liquid, section/snippet files, and app embeds for any hard-coded http:// reference
 
Steps
  1. Confirm the domain shows a Connected status with an active TLS certificate in Shopify admin — Shopify issues and auto-renews this certificate, and a third-party certificate cannot be substituted for it.
  2. Confirm plain-HTTP requests to the storefront redirect automatically to HTTPS; this is Shopify's default behavior once the certificate is issued, not a merchant-configured setting.
  3. Search theme.liquid, section/snippet files, and any app embed for a hard-coded http:// reference (an image, script, or form action) and correct it at that source — Shopify does not scan or rewrite theme code for you.
  
Verify on this platform
 
  • Confirm the domain status reads Connected with an active TLS certificate in Shopify admin.
  • Load representative storefront pages and confirm the browser reports no mixed-content warnings.
 
Rollback
  1. Revert the specific theme or app-embed edit if correcting a hard-coded reference breaks a storefront feature, then re-source that asset over HTTPS before reapplying.
 
Caveats
  • Standard Online Store (Liquid) themes have no merchant-facing control over the TLS certificate itself — treat certificate provisioning as platform-managed and escalate to Shopify support only if a domain stays stuck in a pending or unavailable TLS state.
  • This applies to Online Store Liquid themes; a Hydrogen custom storefront manages its own TLS and hosting outside Shopify's automatic certificate.
 
Official sources
 
 
Cloudflare Workers / Rules
 
Status: supported · Location: Cloudflare SSL/TLS → Edge Certificates, in front of the origin
 
Steps
  1. Set the SSL/TLS encryption mode to Full (strict) once the origin itself serves valid HTTPS, so the edge-to-origin hop is not silently downgraded to plain HTTP.
  2. Enable Always Use HTTPS to redirect HTTP requests at the edge; do not also run a duplicate redirect at the origin without confirming they agree — Cloudflare documents that combination as a source of redirect-loop errors.
  3. Enable Automatic HTTPS Rewrites as a stopgap for legacy first-party HTTP subresource references while the true source is corrected; it only rewrites resources it can confirm are available over HTTPS, and for third-party domains outside Cloudflare's known-HTTPS lists it rewrites active content only, not passive content like images.
  
Verify on this platform
 
  • Confirm the SSL/TLS encryption mode and Always Use HTTPS status in the Cloudflare dashboard.
  • Load the site through Cloudflare and confirm HTTP requests redirect to HTTPS with no redirect loop, then check for any remaining mixed-content console warnings that Automatic HTTPS Rewrites did not catch.
 
Rollback
  1. Disable Always Use HTTPS or revert the encryption mode if enabling it produces a redirect loop with an existing origin-level redirect, then remove the duplicate origin redirect before re-enabling.
 
Caveats
  • Automatic HTTPS Rewrites does not resolve every mixed-content case: resources injected by JavaScript or CSS after page load, and passive content from domains outside Cloudflare's known-HTTPS lists, still need a first-party fix.
  • Do not run an origin-level HTTP-to-HTTPS redirect at the same time as Always Use HTTPS without confirming they agree on the destination.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned hosting, page builder, or headless frontend
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor to confirm every subresource, form action, and redirect destination for the page resolves to HTTPS, and that the TLS certificate for the hostname is valid and renews automatically without manual intervention.
  • Independently load the page and confirm no mixed-content warnings and no HTTP hop anywhere in its redirect chain.
  
Caveats
  • Escalate when the vendor cannot confirm certificate renewal is automated, or cannot identify the source of a persistent HTTP reference.
  • Do not accept a claim of "HTTPS enabled" without seeing a live response that resolves every reference and redirect hop to HTTPS.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Load the production page fresh and confirm zero mixed-content warnings in the browser console.
  2. Trace the full redirect chain for the page and confirm every hop, including the final destination, is HTTPS.
  3. Inspect the TLS certificate served for the hostname and confirm it is valid, unexpired, and matches the hostname.
  4. Rerun Website Safety & Security Checker on the same production URL.
 
Escalate when
 
Escalate when certificate issuance or renewal is not automated and no owner is confirmed, a third-party resource has no working HTTPS equivalent, or a redirect must cross a hostname or vendor boundary you do not control.
 
 
 
 
 
 
 
Website Safety & Security Checker · one finding
 
Protective security header is missing
 
Recommended action: Add the specifically reported protective header at the origin or edge with a policy tested against the site’s required resources.
 
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.