Website Metadata Audit Acceptance Matrix by HTML Page Type
How do I decide which metadata findings are genuine defects for each kind of HTML page?
Create a metadata contract before running the audit. List each HTML page type, the field being tested, whether it is required, the acceptance rule and the exception owner. Apply each rule only to the pages covered by that row, and report machine-readable responses separately. Classify findings as missing, invalid, duplicate, conflicting, intentional exception or inapplicable. After repair, rerun the same page set and contract. A clean metadata result does not prove indexing, accessibility, rankings or conversion performance.
Define the metadata contract before scanning
A website audit is a structured examination spanning technical health, search visibility, content, user experience, performance, accessibility, security and conversion paths. A metadata contract narrows that broad scope by stating exactly which HTML page types and fields this audit will judge.
Sources: The Complete Website Audit Guide: How to Audit a Website from Top to Bottom.
List page types by purpose, such as service, contact, article or utility pages, and decide whether each agreed field is required, optional or inapplicable. Do not promise ranking or conversion outcomes from metadata compliance; the contract defines a release check, not complete website quality.
- Group HTML pages by purpose.
- State required, optional or inapplicable for each field.
- Approve the contract before interpreting scanner output.
Build the page-type acceptance matrix
Mailchimp is described in the supplied audit source as considering SEO, design, technical performance, content and competitors when examining whether website components work properly. A focused metadata matrix should avoid collapsing those broader concerns into one score and should instead define the page-type rule that each row controls.
Sources: The Complete Website Audit Guide: How to Audit a Website from Top to Bottom.
Give each row a page type, metadata field, applicability, acceptance rule and exception owner. For example, a title may be required on an applicable HTML page while an HTML meta description may be optional under the organisation’s documented rule; the matrix records the decision rather than inventing a universal requirement.
- Use one row for one page-type and field combination.
- Make the applicability and acceptance rule explicit.
- Name the owner of intentional exceptions.
Test only the applicable HTML response set
A Hallermann Consulting release check found no missing or invalid required metadata in 170 HTML responses on 2026-10-03 after recorded repairs; machine-readable responses were excluded from the HTML denominator. Use the same denominator discipline by identifying the applicable HTML response set before counting metadata exceptions.
Sources: One-site release crawl and metadata verification.
Apply each matrix row only to the page type and field it names, and report machine-readable endpoints or other inapplicable responses separately. Classify findings as missing, invalid, duplicate, conflicting, intentional exception or inapplicable so the repair owner can see what decision is required.
- Create the HTML denominator before counting defects.
- Report machine-readable endpoints separately.
- Keep missing, invalid, duplicate and conflicting findings distinct.
Report metadata exceptions as decisions
A useful audit asks whether a website works effectively for users and the business behind it rather than only whether it looks good. Metadata exceptions should therefore be reported in the context of the affected page and its purpose, not merely as a scanner total.
Sources: The Complete Website Audit Guide: How to Audit a Website from Top to Bottom.
For every exception, retain the URL, page type, field, observed result, applicable matrix rule, classification, owner and expected outcome. If an exception is intentional, document its reason and owner instead of removing the URL from the tested set without explanation.
- Retain the affected URL and matrix rule.
- Record intentional exceptions rather than hiding them.
- Connect each defect to an owner and expected outcome.
Rerun the same metadata rules after repair
Technical SEO includes multiple infrastructure concerns, including crawlability, indexing, page speed, security and structured data. A metadata rerun should therefore report only what its defined rules establish and should not be presented as proof that every technical concern has passed.
Sources: The Complete Technical SEO Guide for Small Businesses (2026) - eSEOspace.
Repeat the same applicable HTML set, matrix rules and recorded exceptions, then compare the original and rerun results at URL and rule level. Retain unresolved exceptions with their owners and next actions rather than changing the denominator to manufacture a clean result. The Hallermann Consulting figure covered one website and one release window; valid required metadata did not establish indexing, accessibility, functional correctness, rankings or enquiry delivery.
- Repeat the same page set and contract.
- Compare results at URL and rule level.
- State the outcomes that metadata validation cannot prove.
Page-type metadata acceptance matrix
Use one row for each page-type and field combination. Define the contract before scanning so intentional decisions are not confused with defects.
| HTML page type | Metadata field | Applicability | Acceptance rule | Exception owner |
|---|---|---|---|---|
| Service page | Page title | Required | Present and accepted under the documented service-page rule | Website manager |
| Service page | Meta description | Required | Present and accepted under the documented service-page rule | Content owner |
| Contact page | Canonical URL | Required | Present and points to the approved contact-page target | Developer |
| Utility HTML page | Meta description | Optional | Record a value when supplied; absence is not a defect under this example rule | Website manager |
| Machine-readable endpoint | HTML page title | Inapplicable | Exclude from the HTML denominator and report by response type | Developer |
The sample rules are hypothetical structure examples, not universal SEO requirements. Replace them with approved rules for the website being audited.
Related guidance
What follow-up questions matter most?
- Does every response require the same metadata?
- Define the rule by page type. A field can be required for one HTML page type, optional for another and inapplicable to a machine-readable endpoint. Record that applicability before scoring findings.
- What is the difference between missing and invalid metadata?
- A missing value is absent where the contract requires it. An invalid value is present but fails the written acceptance rule. Keep those categories separate because they may need different repairs.
- How should intentional metadata exceptions be handled?
- Record the exception with the affected page type, reason, approver or owner and the rule used during the rerun. Do not make an exception by silently removing the URL from the denominator.
What steps does this workflow follow?
Build a metadata acceptance matrix
- List HTML page types: Group applicable HTML pages by their purpose, such as service, contact, article or utility pages.
- Choose required fields: For each page type, state whether each title, description, canonical or other agreed field is required, optional or inapplicable.
- Write acceptance rules: Describe what counts as present and valid without inventing unsupported performance guarantees.
- Record exceptions: Document intentional exceptions with a reason and owner rather than silently excluding failed pages.
- Test the applicable set: Apply each rule only to the HTML pages covered by that row of the matrix.
- Rerun the same contract: After repairs, use the same page set, rules and exceptions and retain both result sets.