Understand your audit results
Understand LLMIC Pages, Issues and Queue, distinguish incomplete evidence from confirmed findings and prioritize your next actions.
LLMIC audit results are observations about the pages and data captured in a particular crawl. They are not a guarantee of search-engine indexing, rankings or traffic. Begin by checking the active website, crawl source and completion state. Reading those details first helps avoid comparing different sites, dates or evidence layers as though they were the same audit.
What this guide helps you do
An SEO audit report is useful when every score leads back to a page and an observed condition. Learn how LLMIC separates coverage, findings, unavailable evidence and recommended actions before you assign work.
Use Pages to inspect evidence
Pages is the starting point for understanding 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.
Use Issues to find affected pages
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.
Understand source and rendered content
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.
Read unavailable and beta states honestly
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 evidence into an action
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
Next, review crawl setup, prepare reviewed changes, export evidence. Return to the documentation home to explore other guides. If the result differs from these instructions, contact support with your app version and the relevant steps. Remove private information from screenshots and never include API keys or passwords.
Frequently asked questions
Understand LLMIC Pages, Issues and Queue, distinguish incomplete evidence from confirmed findings and prioritize your next actions.
Load a completed crawl that includes the pages you need to inspect. Confirm the crawl scope, capture time, rendering choice, and any filters before interpreting the result.
Review the affected URL, measured field, source or rendered evidence, and the rule that raised the item. Inspect nearby pages and templates because one shared component can create the same pattern across many URLs.
Create a task with the affected URL, observed evidence, intended outcome, smallest safe change, owner, and verification method. Keep the measured finding separate from the proposed fix.
Publish the approved change, run a fresh compatible crawl, and compare the new evidence with the saved result. A resolved local finding confirms the implementation changed; search performance requires separate observation over time.
The check cannot guarantee rankings, indexing, traffic, conversions, inclusion in an AI answer, or a future search-engine action. Interpret it with site context, search performance, and editorial judgment.
Save or export the evidence, assign the approved action, and use the related guides linked on the page for the next check. After implementation, repeat the same workflow against a fresh crawl so the result is comparable.