Confirm which page and measurement mode the report covers
Check the submitted URL, final URL after redirects, scan time and measurement mode before interpreting a warning. A report for the homepage does not describe every product page, account screen or checkout state. WebAnalyzer examines the submitted page and selected domain signals; it does not crawl the entire site.
Static HTML, a browser fallback and lab measurements answer different questions. If the page changes after JavaScript runs, compare the initial response with the rendered page. A finding about an element absent from the initial HTML needs that context before you assign a fix.
Use the public sample report to follow this guide without submitting a website or sharing an email. Its inputs are constructed examples, with source HTML and full results available for inspection.
Read the finding behind the score
Look for the check name, status, evidence and assessment type. An observed fact can still require interpretation: an intentionally excluded account page should not be made indexable just to improve its grade. A heuristic is a prompt for review, while a not-tested result means the report has no measurement for that condition.
A score can also hide a serious issue in one area. Our controlled noindex example makes that concrete:
| Constructed HTML snapshot | Overall score | SEO score | What changed |
|---|---|---|---|
| Baseline | 84 | 72 | Reference HTML |
| Noindex variant | 81 | 55 | Added a search-indexing exclusion |
Use the example without mistaking it for a traffic result
The noindex variant still scored 81/100 overall. Its SEO score was 55/100, and the indexable check identified the exclusion. This is a reason to read critical findings even when the headline grade looks acceptable.
These numbers came from four constructed HTML snapshots with fixed environmental inputs. They are not a customer before-and-after story, and the experiment did not measure Google indexing, visitor conversions or AI citations. The noindex case study shows the exact HTML edit and repeat check.
Build a fix list around the page's job
For a public signup page, first investigate problems that stop discovery or prevent someone completing the form. Then address confirmed usability and performance defects. Review wording and optional enhancements in the context of the page's purpose. An intentionally private page has a different set of priorities.
For each proposed change, write down the evidence, affected URL or template, responsible person and acceptance check. Keep the list small enough to verify. This example is a planning template, not a report of defects found on a customer website.
| Finding to confirm | Proposed action | How to verify |
|---|---|---|
| Accidental noindex | Correct the template or response header | Fetch the deployed page and inspect HTML plus headers |
| Form field has no accessible name | Add an appropriate label | Inspect the rendered control and test with assistive technology |
| Important text absent from initial HTML | Review the rendering approach | Compare the initial response and rendered content |
Recheck the finding, then measure the outcome separately
Run the same URL after deploying the fix. Record changes in measurement mode or scoring version before comparing scores. Verify the specific acceptance check, including manual steps the analyzer cannot perform. The website comparison tool can help review two URLs; retain your original evidence when comparing a page over time.
Track actual outcomes in the systems that measure them: completed forms in product analytics, search visibility in Search Console and performance in appropriate field or lab measurements. A higher diagnostic score alone does not establish better rankings, security or accessibility compliance.
Start a website analysis when you are ready to inspect your page. The score is available without an account; an email unlocks the detailed report. Keep the resulting fix list tied to evidence rather than trying to make every indicator green.