URL Audit: What It Checks and How to Use the Report
Direct Answer
A URL Audit analyzes one specific page in depth rather than crawling an entire website. Site SEO Audit fetches the submitted URL, records the final response, inspects the available HTML and supporting evidence, and organizes findings into confirmed issues, items that need review, and optional opportunities. Use it when you need a focused diagnosis or want to verify a page after changes; use Site Scan when you need multi-page discovery and site-wide patterns.
Documentation
What a URL Audit analyzes
A URL Audit starts with the exact URL you submit. The server requests the page, follows allowed redirects, records the final URL and response, and analyzes the HTML that was available to the audit.
Depending on the page and the evidence available in that audit, the report can include signals such as:
- HTTP status, final URL, redirects, and response timing;
- title and meta description;
- canonical declarations and canonical target validation;
- indexability-related directives;
- H1/H2 structure and heading text;
- HTML language and hreflang declarations;
- structured data detected in JSON-LD;
- Open Graph and social-preview fields;
- favicon or icon declarations;
- selected security-header evidence;
- image ALT signals;
- internal-link counts, anchor context, and selected destination checks;
- content-length and other page-level review signals.
The report does not assume that every detected condition is automatically an SEO problem. The meaning of a signal depends on how confidently it can be measured and whether page context is required.
Website Health is not a count of every warning
Site SEO Audit separates findings into three practical groups.
Issue means an objective and actionable problem was detected. Confirmed issues can affect Website Health.
Needs review means the audit found a signal that requires page or business context before it should be treated as a problem. It does not automatically reduce Website Health.
Opportunity is an optional improvement. It can be useful, but its absence is not automatically treated as an error.
This prevents a report from lowering the score simply because a page does not follow every possible recommendation.
Evidence explains why a finding exists
The report stores evidence from the audited response so you can inspect what caused a finding instead of working from a generic warning.
For example, evidence may show the declared canonical, a resolved canonical target, detected heading text, an image source with its ALT state, or an internal destination that redirected or could not be reached.
Some supporting checks are intentionally bounded. A focused URL Audit may validate selected canonical, hreflang, or internal destinations, but it does not turn one page audit into an unlimited crawl of the host.
Healthy destinations are often summarized instead of being listed one by one. Detailed rows are most useful for redirects, unavailable targets, ambiguous values, or items that need review.
Older saved audits can contain less detailed evidence if they were created before a newer evidence format was introduced. Run a Re-scan when you need the current audit model and current evidence.
Starting without an account and continuing in the workspace
You can start a guest URL Audit without creating an account first.
The initial report is designed to show the page result and useful priority signals before registration. The account workflow is used when you want the complete working environment around the audit, including the full Fix Queue, saved evidence, history, and Re-scan workflow.
Saved member audits remain available from the SEO Audits area subject to the history rules of the current plan.
Re-scan verifies the page after a change
A Re-scan runs the URL through the audit again instead of assuming that an implemented fix worked.
The comparison can show which findings disappeared, which are still present, and which appeared in the newer audit. This makes the workflow:
Audit → inspect evidence → fix → Re-scan → compare.
A Re-scan uses one URL Audit credit. A failed page fetch does not consume a successful audit credit.
The number of available URL Audit credits depends on the active plan. Use Plans & Limits for the current allowance instead of relying on an old saved report.
URL Audit and Site Scan solve different problems
URL Audit is a focused page-level diagnostic.
Site Scan is the multi-page workflow for a verified Project. It is designed to move across multiple URLs, show coverage, find repeated findings, and support site-wide patterns and change analysis.
A URL Audit may make a bounded number of supporting requests while validating page evidence, but that does not make it a full-site crawl.
Use URL Audit when one important page needs detailed investigation. Use Site Scan when you need to understand how a problem repeats across the website.
What a URL Audit cannot guarantee
An automated audit is evidence, not a guarantee of ranking or complete SEO correctness.
The core audit analyzes the response and HTML available to the server. Content or state that exists only after browser-side interaction may not always be represented in the same way as a fully rendered user session.
A recommendation can also require human context. A short page is not automatically bad, a long title is not automatically wrong, and the presence of structured data does not prove that the markup is appropriate for the page.
Use confirmed findings first, review contextual signals second, and treat Website Health as a prioritization aid rather than the final objective.
Questions & Answers
Does a URL Audit crawl the whole website?
No. A URL Audit is focused on one submitted page. It can perform a bounded number of supporting checks for selected targets, but Site Scan is the separate workflow for multi-page crawling and site-wide discovery.
What does Website Health measure?
Website Health summarizes confirmed problems detected by the current scoring model. Items classified as Needs review or Opportunity do not automatically reduce the score simply because they are present.
Do I need an account to run a URL Audit?
You can start a guest audit without an account. An account is used to continue with the complete Fix Queue, saved evidence, audit history, and Re-scan workflow.
Does a Re-scan use another audit credit?
Yes. A Re-scan performs another URL Audit and uses one URL Audit credit. This is intentional because the page is fetched and analyzed again so the new result can be compared with the previous one.
Why can two audits of the same URL produce different results?
The page can change between requests, redirects or headers can change, linked targets can respond differently, and the current audit may use newer evidence or scoring logic. Historical reports are preserved as historical results rather than being silently rewritten.
Practical Check
When reviewing a URL Audit:
- confirm that the final audited URL is the page you intended to test;
- check the HTTP result and any redirect information first;
- work through confirmed Issues before optional improvements;
- open Evidence before changing the page so you know what was actually detected;
- review Needs review items in the context of the page purpose;
- check canonical, indexability, headings, language, links, images, and other saved page signals where relevant;
- make a focused change instead of changing several unrelated things at once;
- run a Re-scan after the change is live;
- compare resolved, remaining, and new findings;
- switch to Site Scan when the same problem may affect many URLs.
Do not optimize only for a higher Website Health number. The useful outcome is a page with fewer confirmed problems, clearer evidence, and changes that can be verified.