Google Search Console SEO Audit: A Step-by-Step Method

A Google Search Console SEO audit is a structured read of the reports Google already keeps about your site, done in a fixed order so that you fix causes before symptoms. Search Console is free, it reports what Google itself recorded, and it is the only place that shows which of your URLs are indexed and why the rest are not. It is not a crawler and it does not score your site, so the audit is something you perform, not something the tool hands you.

The order matters more than people expect. A page that is not indexed cannot have a ranking problem, and a page with a rendering problem will look like a content problem in the performance report. The method below moves from the question of whether Google can see your pages, to whether anyone clicks them, to whether the experience holds up, and finally to what the tool cannot tell you. Set aside a couple of hours for a small site and a day for a large one.

Before You Start: Confirm the Property and the Date Range

Most wasted audits begin with the wrong property. Search Console has two property types, and they report different things. A Domain property covers every protocol and subdomain under a domain, verified through DNS. A URL-prefix property covers only the exact prefix you entered, so the http and https versions, or www and non-www, can each be a separate property with separate data. If you only verified one variant, you are auditing a slice of your site and will draw conclusions from a partial picture.

Check which property holds the data for your canonical version, and prefer the Domain property when you have it. Then set the performance date range to the longest window available, which is sixteen months, and compare it with the same period a year earlier. Seasonality produces far more false alarms than real problems, and a year-over-year comparison is the cheapest way to tell them apart.

Pass One: Indexing Is the Foundation

Open the Pages report under Indexing. It splits your known URLs into indexed and not indexed, and lists a reason for each excluded group. The instinct is to treat every reason as an error, and that instinct is wrong. A large not-indexed count is normal on most sites, because it includes redirected URLs, parameter variations, pages you deliberately blocked, and duplicates that Google folded into a canonical.

What you are looking for is the mismatch between intent and outcome. Take your sitemap, which should list only pages you want indexed, and filter the report to submitted URLs. Any submitted URL that is not indexed deserves a look. Anything that is indexed but absent from your sitemap is worth a second look too, because it often means crawl paths are leaking thin or duplicate pages into the index.

• Crawled, currently not indexed: Google fetched the page and chose not to keep it. This is usually a quality or duplication signal, not a technical fault, so improving the page beats resubmitting it.
• Discovered, currently not indexed: Google knows the URL but has not crawled it. On a small site this points to weak internal linking. On a very large one it can point to crawl budget pressure.
• Duplicate without user-selected canonical or Google chose a different canonical: your canonical tags and Google's judgement disagree. Check whether the page it preferred really is the stronger version.
• Soft 404: the page returns a normal status but reads like an error or an empty result. Fix the page or return a proper 404 or 410.
• Blocked by robots.txt and noindex: confirm every instance is deliberate. A template-level noindex left over from staging is one of the most expensive mistakes an audit can find.

Pass Two: Use URL Inspection as a Microscope

The Pages report gives you groups. URL Inspection gives you a single verdict you can trust, and it is where you confirm a hypothesis. Paste a representative URL from each troubled group and read the indexed version, not just the live one. The two can differ, and the gap between them is the finding: if the live test shows the content and the indexed version does not, the page changed after Google last saw it, or Google could not render it the way a browser does.

Look at the user-declared canonical against the Google-selected canonical, the last crawl date, and the crawl and indexing status. Then view the crawled page and compare the rendered HTML with what you expect. Content that loads only after a script runs is a common culprit when a page is indexed but ranks for nothing related to its main topic.

Pass Three: Read the Performance Report for Decisions

Only after indexing is sound does the Performance report become trustworthy. Clicks, impressions, average CTR and average position are all here, and each one can mislead on its own. Average position in particular blends every query and every country into a single figure, so a page can show a flat average while improving for its main query and sliding for a dozen marginal ones. Always break position down by query or by page before you draw any conclusion.

Three cuts repay the effort in almost every audit. First, sort pages by impressions and look for high-impression pages with weak CTR. These are pages that already rank well enough to be seen, where the title or snippet fails to earn the click, so rewriting them is often the fastest win available. Second, filter for queries where the average position sits in the lower half of page one or the top of page two. These are pages close to a meaningful jump and are candidates for better internal links, a clearer match to the query, or extra depth. Third, compare the two date ranges and sort by click loss to find pages that used to earn traffic and stopped.

Pass Four: Page Experience, Mobile and Core Web Vitals

The Core Web Vitals report groups URLs into good, needs improvement and poor, separately for mobile and desktop. The data comes from real Chrome users over a rolling window, which means it is slow to react. After you ship a fix, expect weeks before the report moves, and do not mistake that delay for failure.

The report groups URLs that share a template, so one slow template shows up as hundreds of affected pages. That is useful: the fix is a single change to the layout, image handling or script loading of that template, not hundreds of page edits. Start with the group holding the most valuable pages, not the group with the largest raw count. Low-traffic pages with poor scores matter far less than your top landing pages.

Pass Five: Enhancements, Links and Security Flags

Under Enhancements, Search Console lists the structured data types it detected, such as breadcrumbs, products, reviews or videos, with valid, valid with warnings and invalid counts. Errors here can cost you rich results but rarely cost you rankings, so rank them below indexing problems. Warnings on optional fields can often wait. Invalid items on a type you actually depend on for visibility should be fixed first.

Check the Sitemaps report to confirm that Google processed each file successfully and that the discovered URL count is close to what you submitted. Then open Manual actions and Security issues. Both should be empty. If either is not, everything else in this audit becomes secondary until it is resolved.

What a Search Console Audit Cannot Tell You

Search Console shows how Google sees pages it already knows about. It will not crawl your whole site the way a desktop crawler does, so it cannot report broken internal links, missing title tags or heading structure problems across pages Google has not visited. It does not show competitors, it does not show rankings for queries you never appeared for, and it does not measure conversions. That is why people searching for a Search Console audit tool are often really asking for something that combines it with a crawler and an analytics source. Treat Search Console as the ground truth on indexing and search visibility, and pair it with a site crawl and your analytics data for everything else.

Finish the audit by writing down no more than ten actions, ordered by how much they unblock. Indexing fixes first, then snippet rewrites for high-impression pages, then template-level experience work, then enhancements. Record the date and the baseline figures for each, so you can check whether the change worked. Repeat the full process quarterly, and watch the Pages report monthly for any sudden jump in excluded URLs.