A quarterly audit checks whether the site remains discoverable, crawlable, indexable, secure, and eligible for intended Search features. Search Console supplies Google's processed evidence and representative examples; a crawler, server logs, deployment configuration, analytics, and the site's canonical inventory supply the completeness it does not.
Do not turn the audit into a target of “100% indexed.” Google explicitly says duplicates, redirects, removed pages, and deliberately excluded URLs should often remain unindexed. The goal is for every important intended canonical to be discoverable, indexable, and served correctly.
Define scope and preserve evidence
Record:
- Domain and relevant URL-prefix properties;
- audit date and comparison quarter;
- canonical URL inventory by template, locale, and sitemap;
- releases, migrations, infrastructure changes, and incidents;
- business-critical URL and feature groups;
- external crawler and log coverage;
- known limitations or inaccessible systems.
Export current report summaries and representative examples before remediation. Search Console classifications can change after recrawl and most example lists are capped.
1. Governance and access
Review:
- verified and delegated owners;
- full and restricted users;
- unused ownership tokens;
- ownership history;
- Domain/URL-prefix scope;
- GA4, Merchant Center, and BigQuery associations;
- OAuth clients and scheduled exports.
The organization should retain a durable verified owner. Remove obsolete users and tokens carefully: the same verification token can support other Google services.
2. Security and manual actions
Open Security Issues and Manual Actions for every relevant property. A clean report is authoritative only for the detected conditions those reports cover; it does not replace application security testing, vulnerability management, spam monitoring, or server-log review.
If an issue exists, separate remediation from review submission. Fix the full affected pattern, preserve evidence, validate access, and follow the report-specific review process.
3. Canonical inventory and indexation
Compare three populations:
- first-party intended canonical inventory;
- canonical URLs submitted in sitemaps;
- Google-known indexed and non-indexed totals.
In Page Indexing:
- review changes by exact reason and source;
- filter to submitted sitemaps;
- confirm expected duplicates, redirects,
noindex, and removed URLs; - investigate new website-caused spikes;
- sample high-value URLs with URL Inspection;
- check declared versus Google-selected canonical;
- verify fixes on the live page before requesting validation.
The headline indexed/non-indexed totals are comprehensive from Google's perspective for URLs it knows, but each issue example list is limited to 1,000 and is not a full remediation list. A URL absent from the report might simply be unknown to Google.
4. Sitemaps and discovery
For every submitted sitemap or index:
- confirm the fetch succeeded;
- compare submitted and discovered counts with first-party output;
- include only canonical, indexable, successful URLs appropriate to the sitemap;
- inspect stale, redirected, blocked, or erroring entries;
- verify accurate
lastmodwhere supplied; - confirm all important sections have crawlable internal links.
The Sitemaps report lists sitemaps submitted through the report/API, not every sitemap Google may discover. Submission is a discovery signal, not proof of crawling or indexing.
5. Crawling and host health
Crawl Stats is available only for root-level properties and is designed primarily for advanced or larger sites. Review its recent history for:
- host availability;
- DNS, connection, and robots.txt issues;
- response-code distribution;
- crawl purpose and file type;
- response time and download size;
- unexpected host or URL-pattern activity.
Crawl Stats counts requests, including redirects and repeated requests to the same URL. Its URL examples are representative. Use verified server logs for the requests that actually reached the infrastructure, and an external crawler for site-wide internal discovery.
For small sites, avoid inventing a crawl-budget project without evidence of a real serving or discovery problem.
6. Rendering, robots, and response behavior
Use a crawler and representative live URL tests to verify:
- final status codes and redirect chains;
- robots.txt behavior;
- meta and HTTP
noindexdirectives; - canonical and alternate links;
- rendered primary content and internal links;
- JavaScript resources required for rendering;
- mobile parity;
- soft-404 patterns;
- parameter, faceted, and internal-search spaces.
Search Console has no comprehensive crawl export. A successful URL Inspection live test for one URL does not validate a whole template.
7. Page experience and HTTPS
Core Web Vitals uses CrUX real-user field data and groups similar URLs. Review mobile and desktop separately, changes in Poor/Needs improvement/Good groups, and whether a template release aligns with the movement. The details table is limited and URLs/groups without enough data are omitted.
Use lab tests and performance telemetry to diagnose a field-data group; Search Console does not identify the code causing LCP, INP, or CLS.
Review HTTPS for non-HTTPS canonical pages and reported reasons. Validate certificates, redirects, canonical tags, mixed content, and internal links independently. A healthy HTTPS report does not constitute a full TLS or security audit.
8. Structured data, video, and commerce
Open every report relevant to the site's intended features:
- rich-result and unparseable structured data;
- Video Indexing;
- Product snippets and Merchant listings;
- Merchant opportunities;
- AMP or other surviving enhancements.
Distinguish critical errors from optional improvements. Counts can represent structured-data items, not pages, and reports list samples rather than all markup. Validate representative templates with the Rich Results Test and compare findings to source/rendered markup.
Valid markup establishes eligibility, not a guarantee of a rich result.
9. Performance as a technical cross-check
Compare equivalent quarters and isolate page templates, hosts, countries, devices, and appearances affected by technical changes. A Performance decline can help prioritize a confirmed issue, but it does not diagnose crawling or prove causality.
Watch for:
- sudden loss after a deployment or migration;
- performance credit moving to an unexpected canonical;
- mobile-only or country-specific template failures;
- disappearance of a supported appearance;
- indexed-page decline aligned with click/impression loss.
Evidence-source matrix
| Need | Best evidence |
|---|---|
| Google's indexed state for one URL | URL Inspection indexed evidence |
| Current crawlability/rendering for one URL | Live test plus direct fetch |
| Complete internal URL/link inventory | First-party inventory and external crawler |
| Requests received from Googlebot | Verified server logs |
| Google-known indexation totals | Page Indexing |
| Real-user CWV groups | Search Console/CrUX |
| Root cause of CWV problem | Lab tools and performance telemetry |
| Structured-data syntax on a template | Rich Results Test and rendered/source markup |
| Complete security posture | Security tooling; not Search Console alone |
Prioritize the audit backlog
Give highest priority to confirmed issues that affect important canonical groups and have a credible mechanism:
- security/manual action or sitewide access failure;
- accidental
noindex, robots block, canonicalization, or serving errors; - migration/redirect/sitemap failure affecting high-value URLs;
- template-level rendering, structured-data, HTTPS, or experience regression;
- crawl inefficiency with demonstrated capacity/discovery impact;
- optional enhancements and low-impact hygiene.
For every ticket include affected scope, representative URLs, reproduction, expected state, owner, validation method, and rollback plan.
Related content
- The Page Indexing report: complete guide
- Crawl Stats: complete guide
- Core Web Vitals: complete guide
- Report completeness & row limits