Site Auditor

Outcome

You will know when to use Site Auditor, how to run an audit, and how to read the results so the findings translate into prioritized work rather than a long list nobody acts on.

Best Use Cases

• Prelaunch review, before a site goes live or before a major content push
• Ongoing quality checks at a regular cadence, for example monthly or quarterly
• Investigating whether a site changed after a release, a theme update, or a content migration
• Confirming a fix landed correctly when remediating an earlier finding

How To Use It Well

Treat the audit as a decision-support tool. Look for repeat issues, high-severity findings, and patterns that map to visible customer problems rather than trying to act on every low-signal item immediately. The most useful audits are the ones that change a team’s next-week plan, not the ones that produce the longest report.

Severity Reference

The auditor groups findings by how much they affect real visitors and operations. Use the severity column to triage what to work on first.

Severity	What it means	Typical action
Critical	Blocks core visitor or operator journeys, or signals a security risk	Fix this release cycle
Warning	Noticeable degradation, performance, or quality issue	Schedule for the next maintenance pass
Info	Useful context, recommended improvement, or polish	Address when convenient or batch with related work

Run an Audit

1. Open the site in TMXIO and navigate to the Site Auditor area.

2. Start a new audit. Most sites can be audited against the default profile; a few may have project-specific checks enabled.

3. Wait for the run to finish. Larger sites take longer; you do not need to keep the tab open.

4. Open the completed report and sort findings by severity. Start at the top.

5. For each finding you intend to act on, record it as an issue or task in your tracker so the work survives outside the audit view.

Reading the Results

1. Look at the Critical band first. These are findings that are worth interrupting other work to address.

2. Look at the Warning band for patterns. A single warning across many pages is usually a template-level issue and is cheaper to fix once than to chase per page.

3. Skim the Info band for anything that pairs naturally with work you already have planned.

4. Compare the report to the previous audit if one is available. Findings that have returned after being fixed are often the most important signal in the whole report.

Match audits to visible problems

When a customer or stakeholder reports something specific, run an audit and search the results for that area before opening a deeper investigation. The audit will often surface a related finding that explains the symptom without any extra digging.

What Success Looks Like

• Audits run on a predictable cadence, not only when something has already gone wrong
• Critical findings are closed inside the cycle they are detected
• Patterns of warnings turn into one template-level fix rather than many page-level fixes
• Audit history is reviewed, so regressions are obvious