SEO Audit vs SEO Reporting

The split

A checklist run on demand compared with a record kept over time

The practical difference is replaceability. A snapshot from last quarter can be replaced by running the check again, whereas last quarter's outcomes cannot be recreated if they were never recorded. Because Search Console retains only 16 months, a reporting process that never exports its data has a hard horizon, while an audit has no equivalent limit.

The two also serve different readers. An audit is written for the people who will change the site, so it needs the URL, the evidence and the fix. A report is written for the people who decide where effort goes, so it needs a trend, a comparison period and a plain statement of what changed. Mixing the formats produces a familiar failure: a report padded with a hundred audit findings that nobody can act on, or an audit that opens with traffic charts and never reaches a defect.

Signals

Which signals feed the audit and which feed reporting

A useful test for any metric is whether it can be re-fetched. If asking again returns the current answer, the metric belongs to the audit. If the value depends on what happened during a window and that window has closed, it belongs to reporting.

Two rows deserve care. The Page indexing counts look like reporting because they are charted over time, but they describe the state of crawled URLs, and Google updates an issue's instance count whenever it crawls a page with known issues. They are an audit signal that happens to have history. Field performance is the reverse: it feels like a diagnostic, but web.dev describes CrUX as a rolling average over the previous 28 days, which makes it a record of recent user experience and a poor tool for measuring the effect of changes during development.

Where they disagree

Why a page can pass the audit and still fail in reporting

Core Web Vitals show the split inside a single topic. web.dev advises starting with field data to evaluate site health and using lab tools such as Lighthouse to diagnose how to improve it. The Lighthouse performance score is a lab measure and often does not correlate with field Core Web Vitals, so a green lab score is not evidence that users are having a good experience. PageSpeed Insights shows field and lab results together for public URLs, and Search Console reports field data grouped by similar pages.

The same disagreement appears in indexing. A page can be indexed and eligible, so the audit finds no blocker, while the Performance report shows no impressions for it. The audit checks for blockers, and only reporting shows whether an eligible page turned that eligibility into visibility. The reverse also happens: a URL can accumulate impressions while a later audit finds a canonical conflict, which means the defect is a risk to existing visibility, not proof that the page is failing.

Field data has a coverage edge of its own. CrUX aggregates only opted-in Chrome users on supported platforms, and origins and pages must be public and popular enough to appear, with the exact threshold undisclosed. A low-traffic page can therefore pass a lab test and have no field data at all, so the absence of a field result is a coverage limit, not a pass.

Audit design

What makes an audit defensible

Start with sampling. The Page indexing report caps its example list at 1,000 rows and does not guarantee that every URL in a given status appears, so on large sites the list is a sample, not a census. Pick a handful of URLs per template, inspect each, and extend a finding only to pages that share that template.

Then name the evidence behind each finding. URL Inspection returns two different things: the indexed view, which reflects the most recently indexed version of the page, and the live test, which fetches the page in real time. The live test cannot determine canonical selection and does not check sitemaps or referring pages, and a pass confirms only that Google-InspectionTool can access the page for indexing, not that it will be indexed. A finding based on the live test should therefore never be used to claim anything about the Google-selected canonical.

Respect the order of dependencies. When robots.txt blocks crawling, the Indexing allowed field always shows Yes, because Google cannot see a noindex directive on a page it cannot fetch. An audit that reads that field without first confirming Crawl allowed reports a clean result for a page whose directives were never evaluated.

Finally, rank findings by consequence: defects that block indexing first, defects that degrade a page already earning visibility second, and refinements to pages that already work last. After a fix, indexing requests are limited by daily quotas, do not guarantee inclusion, and Google recommends a sitemap when many pages are involved, so request indexing only for the few pages that matter most.

Reporting design

What makes a report trustworthy

Close the window early. Search Console data is usually available within two to three days, so a report that includes the most recent days understates them. As a recommendation, end the reporting window at least three days before the report is written, and state the window in the header so that a later revision is not mistaken for an error.

Mind the clock. Except in the 24-hour view, the Performance report tracks and labels daily data in Pacific Time, so a daily series will not line up with an analytics tool set to another time zone. Compare weekly or monthly totals across systems rather than single days, and expect the Analytics side to differ further because it tracks only users who have JavaScript enabled.

Quote the right totals. The Performance table displays at most 1,000 rows and omits anonymised rare queries, while chart totals include them unless a query filter is applied. Summing table rows therefore undercounts volume. Quote chart totals for volume, use the table only for ranking, and remember that adding a page or Search appearance filter makes the chart and table aggregate differently.

Compare like with like. Google's guidance for judging a change is to compare against a similar earlier period and to confirm that the improvement maps closely in timing to the change. It also warns that isolating one change is difficult, because news events or competitors can move the same numbers, and it treats position as a weak signal on its own in favour of trends in impressions and clicks. Add an annotation on the date of every change so that the chart carries its own explanation.

Plan for retention. Only 16 months of Search Console data are kept, and Search, News and Discover data cannot be combined in the browser, so a recurring export is the only way to hold a longer baseline or compare surfaces side by side.

Workflow

How the audit and reporting work together in five steps

1. 01

   Run the audit to list state issues

   Collect indexing, canonical, markup and performance findings from a crawl and from URL Inspection, and record which evidence supports each one.

2. 02

   Rank issues with reporting data

   Weight each finding by the impressions and clicks of the pages it affects, so that fixes on pages with visibility come first. This ordering is a recommendation, not an official rule.

3. 03

   Fix and verify the state

   Use the live test in URL Inspection to confirm a page is accessible after a change. For indexing issues, Google's validation typically takes up to about two weeks, but in some cases can take much longer, so a missing result after two weeks is not proof that the fix failed.

4. 04

   Measure the effect in reporting

   Compare the period after the change with a similar earlier period in the Performance report, and add an annotation so the change is visible on the charts. When a drop appears, the method in the guide to organic traffic decline diagnosis narrows the cause.

5. 05

   Repeat the audit on a schedule

   web.dev cites Google research showing that most performance improvements tend to regress within six months, so a periodic re-run, quarterly as a baseline and after major releases, can catch regressions early.

Limits

What each side cannot show

An audit is only as current as its source. URL Inspection's indexed view is the last stored copy of a page, and the Google-selected canonical it reports can be a few hours out of date compared with the index. The Page indexing report keeps an issue in its table until 90 days after the last instance was marked as gone, and shows 404 errors only for URLs that returned them in the past month, so a clean-looking table can still reflect resolved history.

Reporting has its own blind spots: the two to three day lag, rare queries omitted for privacy, a 16-month horizon and daily data in Pacific Time. Neither side shows cause by itself. An audit finds a defect without proving that it cost traffic, and a report shows a change in traffic without proving what produced it, which is why the workflow above pairs them.

References

Sources and further reading

• GoogleURL Inspection tool (Search Console Help)
• GooglePage indexing report (Search Console Help)
• GooglePerformance report: troubleshooting data discrepancies
• GooglePerformance report: common tasks and use cases
• GoogleGoogle organic search traffic report (Analytics Help)
• GoogleCore Web Vitals workflows with Google tools (web.dev)
• GoogleChrome UX Report methodology
• SEO AnalyserWeb Audit
• SEO AnalyserTraffic Analytics
• SEO AnalyserAI SEO Analyzer
• SEO AnalyserOrganic Traffic Decline Diagnosis