Improve the security condition behind a finding, then use the score as a summary. Changing headers simply to make a checker green can create a policy that is ineffective or breaks legitimate parts of the site.
This sequence is for public-page configuration findings. It does not replace an application assessment or incident investigation.
First confirm what failed
Record the exact URL, final response, timestamp, and evidence. Check whether the scanner observed a missing value, an unexpected value, or could not complete the measurement.
Open the page in a browser and reproduce the relevant symptom. If the scanner reports a certificate issue, confirm the affected hostname and connection path. If it reports mixed content, identify the actual request rather than assuming every resource needs changing.
An unavailable check belongs in an investigation queue. It cannot establish either a vulnerability or successful recovery on its own.
Repair transport problems with the responsible owner
For an HTTPS problem, have the hosting or infrastructure owner inspect the hostname, certificate deployment, renewal process, and redirects. Confirm the correct destination before changing redirects so that paths and query parameters needed by the site are preserved.
For mixed content, identify the source of the HTTP URL and whether an HTTPS version is supported. MDN's mixed-content guide explains how browsers handle insecure subresources. Recheck the affected page and its function after replacing or removing the resource.
Design a policy instead of collecting headers
Choose header values for the actual application. Avoid enabling HSTS across subdomains without checking their HTTPS support. Avoid a restrictive CSP until the site's required resources and interactions have been tested.
For a CSP change, consider report-only observation before enforcement and review what information the reports contain and where it goes. A report-only policy observes potential violations; it does not enforce the restrictions. See MDN's CSP guide.
The header explainer gives context for choosing the right control.
Keep each change reviewable
Use a separate work item for a policy change that can affect behavior:
Illustrative task: restrict which sites may embed a public service page. Owner: the site's developer. Before release: confirm whether an approved partner needs to embed it. Verification: inspect the returned policy and test both the permitted and blocked embedding cases. Rollback: restore the previously reviewed configuration if the approved journey breaks.
That is more useful than “add X-Frame-Options for five points.” It explains the intended protection and a legitimate-use constraint.
Verify the published result
Check the final response after the change reaches the public site. Include representative pages and error responses when they are within the release scope. Test important browser interactions separately.
Close the original finding only when fresh evidence supports the specific correction. If the recheck is incomplete, record the attempt and retain the unresolved state. If the score changes because coverage changed, do not call that a security improvement.
Keep broader controls on the plan
Public headers say little about privileged accounts, update practices, restore readiness, or access control in the application. Use the small-business security checklist to track those responsibilities.
A free PageVital snapshot can start this review. Its result is evidence for the returned public page, not a certificate of security or compliance.