Understand your audit results
Updated
An audit can give you plenty of findings. The useful question is: which one deserves your attention next?
Start with the evidence behind each result. Check the page, the crawl and whether the measurement is complete. Then decide what to change.
This guide helps you read Pages, Issues and Queue without confusing missing data with a confirmed problem.
From observation to a verified result
- Read the evidence
Confirm URL, response and crawl scope. - Is evidence complete?
If not, obtain missing inputs before concluding. - Choose a specific action
Preserve intentional settings and page context. - Recheck after the change
Fresh evidence establishes the result.
Unavailable data is not zero. A manually completed task is not a verified fix.
Start with the individual URL
Pages helps you understand an individual URL. Review its response and the available page-level information before acting on a summary.
A successful HTML response, a redirect and a failed request are different situations. A failed request may prevent content checks from running, so missing measurements should not automatically become a missing-title or missing-heading conclusion.
Find the pages behind each issue
Issues groups findings so you can investigate recurring patterns. Open the affected URLs and read the recommendation in context.
Several pages with similar wording may share a template, but similarity alone does not prove a common implementation cause. Check representative pages and the actual website template before applying a site-wide fix.
Keep intentional exclusions separate from accidental errors.
Check which version of the page was measured
The original HTML response and a browser-rendered page can differ. Scripts may add headings, links or metadata after the initial response.
When the app exposes evidence from both layers, keep their meaning separate. Seeing a heading in a browser does not prove it existed in the source response, and a source-only result does not establish what every search engine ultimately processed.
Know when the evidence is incomplete
An unavailable measurement is not zero. Incomplete rendering, missing provider access or an older saved crawl can limit what a dashboard can establish.
Content Refresh and Content Decay are labeled beta and use crawl-related freshness and quality signals. Treat those signals as prompts for investigation, not as measured proof of traffic loss or a guaranteed reason to rewrite a page.
Turn a finding into a specific task
Move selected findings into Queue when you know what you intend to investigate or change. Preserve the URL, observed issue and reason for the task.
After making a change, verify the actual page again. Marking a task complete is an administrative step; fresh evidence is needed to say the underlying issue is fixed.
Traffic movement afterward can have other causes and should be described accordingly.
Quick reference
| Result | How to interpret it |
|---|---|
| Confirmed finding | Inspect the affected URL and evidence |
| Unavailable input | Obtain the missing data before concluding |
| Partial crawl | Coverage is still incomplete |
| Manually completed task | Does not independently verify a fix |
Continue learning
Ready for the next step? Start here: review crawl setup, prepare reviewed changes.
If you still need help, contact support with your app version and the steps you tried. Leave out passwords, API keys and private account details.
Published by LLMIC. Documentation reviewed on 24 September 2026.