READING A REPORT
How should a MaxAuditor report be read?
The most useful part of a report is not the total score; it is the evidence beside each finding. This guide shows how to verify a result instead of reducing every observation to a simple good-or-bad label.
1. Start with the observed value
For a security-header finding, read the returned header value. For a redirect finding, read the status codes and URLs in the chain. A Missing label alone does not identify the configuration layer that caused it.
If Content-Security-Policy is absent, the cause may be the application, reverse proxy, or CDN. Confirm the production response first, then change the layer that actually controls it.
2. Read severity in context
Critical and high findings are useful candidates for earlier review, but impact depends on the product. A camera policy on a site that never asks for camera access is not operationally identical to a broken TLS redirect.
Consider the effect on user data, session safety, search access, and the publication path separately. Turn the report severity into a work priority only after that context is understood.
3. Not detected does not always mean nonexistent
Some settings live in a provider dashboard, authenticated session, or later request stage. A signal that is not visible in public HTML does not prove that the feature exists nowhere.
Use the report as a starting point for those cases. The browser Network panel, application configuration, CDN dashboard, or provider console may be needed for a second check.
4. Worked example: www redirect
If both example.com and www.example.com return 200, both addresses may look functional to a visitor. If canonical tags, the sitemap, and shared URLs all use example.com, permanently redirecting www to the bare domain creates a more consistent public identity.
After the change, the expected evidence is a direct 200 on the canonical host, a 308 from the www host that preserves the path, and a canonical tag that uses the preferred host. This is an interpretation example, not a scan result for a real website.
5. Worked example: a missing security header
If X-Content-Type-Options is missing, the first question is not ‘which line should I paste?’. Identify which layer serves the final response. If the application sets the header but the CDN removes it, changing application code alone will not fix the public response.
After the change, request the production URL again and verify the header on the final response. If the report still does not see it, check cache state, the selected domain, deployment status, and any proxy layer that can modify headers.
6. Do not use score movement as the only success measure
Adding a header can increase a score while a wrong value can still break the site. Score movement therefore does not replace behavioral verification.
For CSP, consent, redirects, and robots rules in particular, test the real user path and browser console again. The change should improve the intended control without making the site harder to use.
7. Use the export as a maintenance record
JSON or text exports can be attached to a deployment note, bug ticket, or maintenance task. The timestamp and final URL help make a later repeat check meaningful.
The report contains public technical signals, but it should still be handled carefully when combined with private project information. Do not add passwords or secret keys to exported notes.