An audit score is most useful when you know what it counts. In Shane’s Technical Site Audit, the HTML audit gives equal weight to eight structural checks. It can quickly surface missing page elements, but the percentage alone cannot tell you whether a page is ready for customers or search engines.
Here is how to read the result, spot the details that need a human review, and turn the findings into a practical publishing decision. For a wider page-review workflow, see the technical SEO checklist.
1. Read the percentage as eight yes-or-no checks
The tool divides the number of passing checks by eight, multiplies by 100, and rounds to the nearest whole number. Six passes produce 75%. Seven produce 88%. Eight produce 100%.
Each check has the same weight. A missing title changes the percentage by the same amount as a missing Open Graph title, even though their practical importance can differ. The result does not grade the severity of an issue or estimate its effect on traffic.
The current checks are:
- Title tag: the first title element has text after surrounding whitespace is removed. The result shows its character count.
- Meta description: the first matching description tag has a nonempty content value. The result shows its character count.
- One clear H1: the parsed HTML contains exactly one H1 element.
- Viewport meta: a viewport meta element is present.
- Canonical link: a canonical link element is present.
- Open Graph title: an og:title meta element is present.
- Image alt attributes: every image element in the supplied HTML has an alt attribute.
- Links found: the parsed document contains at least one link in its link collection.
Read the individual results before the percentage. If you report the score, include the number of passing checks and the input you used: “Seven of eight structural checks passed on the saved HTML for our pricing page.” That is more informative than “Our website is 88% optimized.”
2. Check the content behind each green result
Several results confirm presence rather than correctness. An empty H1 can still satisfy the one-H1 count. A canonical element without a useful destination can pass. An Open Graph title element can pass even if its content is empty. A viewport element can pass without a valid mobile-layout value.
Review those elements on the actual page:
- H1: does the heading clearly describe the page, and is it visible where a visitor expects it?
- Canonical: does the URL identify the intended preferred page? Open it and confirm it is the right destination.
- Open Graph title: does the sharing title contain accurate, useful text?
- Viewport: does the page work at a narrow phone width without requiring sideways scrolling?
The title and description checks also need judgment. The displayed character counts are observations, not pass/fail length targets. A very short title can pass while saying little about the page. A description made only of spaces can pass because that field is not trimmed before evaluation.
The tool reads the first matching title and description. It does not flag duplicates for those fields. If a theme, plugin and page template each add metadata, inspect the source for repeated tags and decide which component should own them.
3. Review image meaning, not just the alt attribute
The image check asks whether an alt attribute exists. It does not judge whether the text describes the image well. An empty alt attribute counts as present, and a page with no image elements passes this check too.
That can be appropriate. A purely decorative image may need empty alternative text so it does not interrupt a screen-reader user. An informative image needs text that communicates its purpose in context. A product image, chart or instructional screenshot requires a different review from a decorative border.
For example, a page containing three images with alt attributes will pass even if all three descriptions say “image.” Review the images alongside the surrounding copy. Replace generic wording where the image carries useful information; keep decorative images quiet. The green result confirms attribute coverage, not accessibility quality.
4. Treat the link count as an inventory clue
“Links found” passes when the parsed HTML contains at least one link. It does not request the destinations, check status codes, detect redirects or decide whether the wording is useful.
The accompanying “relative links” count also has a narrow meaning: it counts link addresses that do not begin with http:// or https://. This can include fragment links, email links and protocol-relative addresses. An absolute link to your own domain is excluded from that count. Do not use it as a count of internal pages.
Follow the links that matter to the visitor’s next step: the main action, pricing information, supporting evidence and contact route. Check that each destination opens and matches the promise of the link text. A page can have many links and still send its primary action to the wrong place.
5. Keep the input and the live-page scan separate
The eight-check audit works on HTML you paste or load from a saved file. It parses that input into a document; it does not run the page’s scripts. If JavaScript adds metadata, headings or links later, those changes will not appear unless they are included in the HTML you provide.
Choose one input method for a before-and-after comparison and record it. “Page source saved before publication” and “HTML copied from the rendered document after loading” can contain different elements. Comparing them without noting the difference can make a score change look like a fix when the input changed instead.
The separate Live Page Scan accepts a public HTTPS page URL and returns its title, description and readable content. Its current interface requires sign-in and states that each successful scan uses one credit. It is a separate one-page reading workflow, not the same eight-check score. Neither view is a full-site crawl or a page-speed test.
6. Turn the result into a short fix-and-recheck record
Keep a small record outside the tool with the page URL, date, input method, failing check, proposed change and recheck result. The HTML audit has no built-in report download or saved audit history. Save the source file and your notes if someone else will review the work.
A useful record could read: “Pricing page, 4 November 2026, saved page source. Seven of eight checks passed; meta description missing. Add an accurate description in the page template, publish, then inspect fresh source and rerun the same checks.”
After the recheck, review what the percentage does not cover: whether the page can be indexed, whether important destinations work, how it behaves on a phone, whether keyboard users can complete its main action, and whether the visible claims are accurate. Choose separate checks for performance and accessibility when those are part of the release requirements.
Use the score to catch omissions and confirm a bounded change. The strongest result is a page with clear information, working actions and a record of what you actually checked.