Mualis field guide

What a website health check can tell you

A practical way to understand what your public website can prove, what a bounded audit can observe, and which questions need evidence from somewhere else.

Run the free Mualis audit

The boundary

A health check is a bounded observation of a public HTTPS site. It reports what was available in that run; it does not turn an unavailable signal into a guess.

01 / The observation

What it can assess

A website health check starts with the public response from a site. It can inspect what a visitor or crawler can retrieve from a public HTTPS homepage and describe that evidence in context. It is a useful starting point for deciding what to check next, not a claim about everything happening around a website.

Five ways Mualis organises the evidence

Technical SEO

Page metadata, canonical and indexability signals, links, redirects and structured data.

Content

Headings, visible text, page structure and the information a public page exposes.

Usability

Mobile viewport and image alt signals that help describe the page experience.

Performance

Response time, response size, content type and the headers returned by the site.

AI-search readiness

Structured data and related site-structure signals, without claiming visibility in external AI answers.

Public signals it may inspect

  • Public HTML, page metadata, headings and visible text
  • Links, redirects and the response paths they take
  • Canonical, robots, sitemap and other indexability signals
  • Structured data found in the page markup
  • Image alt text and mobile viewport signals
  • Response headers, content type, response time and response size

02 / The interpretation

How to read the findings

The most useful question is not simply “is this good?” It is “what was observed, where was it observed, and what remains unknown?” Keep the evidence and its limits together as you decide what to do.

Measured

The signal was retrieved and evaluated during this audit run.

Unavailable

The run could not observe a usable value, so no result is invented.

Source

The URL or response context shows where the observation came from.

  • Look for the observed value and its source URL before deciding whether a finding applies to your wider site.
  • Treat a priority as a next consideration grounded in an observed issue. It is not a guarantee of rankings, traffic or visibility.
  • Use repeat audits to compare what changed. A later run can show a different observation, but it still describes that run rather than predicting an outcome.

03 / The limit

What may remain unmeasured

Some important website questions depend on external datasets, real-user telemetry or a broader research method. They should stay labelled as unknown when this audit has not measured them.

  • Search rankings or how a page appears for a particular query
  • Competitor positions or comparisons with other sites
  • Backlinks and the authority of referring sites
  • Core Web Vitals or real-user performance
  • Visibility in external AI answers

Structured data belongs to the AI-search-readiness category because it is a site-structure signal. Finding structured data is not evidence that a site appears in external AI answers.

04 / The next pass

A practical next-step checklist

  1. 01Verify the evidence: read the observed value and follow its source URL or response context.
  2. 02Separate unknowns from failures: an unavailable signal needs a different next step from an observed issue.
  3. 03Address an observed priority: choose the next consideration that fits your site and your team.
  4. 04Rerun the audit: compare the new observation with the previous run and record what changed.

See your evidence

Run the free Mualis audit

Enter a public HTTPS homepage. The flow reports what Mualis can observe in that run, with the evidence boundary kept visible.

Start the audit