Google Search Console SEO audit: a checklist with pass/fail thresholds

Most Google Search Console (GSC) “audit” guides are a tour of the left-hand menu — open this report, then open that one, with no number attached to either. This one is a checklist instead: ten steps, in the order that actually matters, each with the exact figure that turns a reading into a problem. Run it against your own SEO monitoring dashboard or straight from Search Console, and you can finish it in one sitting.

You do not need any paid tool to run this audit. Everything below reads from a report Search Console already gives you for free, and each step names the number to check and the value at which it stops being fine. Two steps near the end genuinely run out of what the free tool provides — those are flagged as their own bounded section, not folded into the checklist.

What Search Console can and cannot audit

Search Console is a reporting layer on top of Google’s own crawl and index of your site — it tells you what Googlebot found, whether it indexed the URL, how the page performed in Search, and whether a manual reviewer or an automated system flagged it. That’s a real, checkable audit. It is not a crawl of your site.

Search Console never independently crawls your site the way a standalone crawler does. It reports on URLs Googlebot already visited, on its own schedule, for its own reasons — it won’t tell you about a broken internal link, a duplicate title tag across two pages, or an orphaned page that Googlebot has not found yet the way a dedicated crawler would. If you need that specific job, a crawler such as Screaming Frog’s SEO Spider is the honest tool for it, not a Search Console report stretched to cover ground it doesn’t have data for. The same boundary applies to any dashboard built on top of Search Console’s own API, including the one this site monitizes: a reporting layer inherits exactly the data Search Console exposes, and none of it is an independent crawl.

What Search Console does uniquely well is the reverse job: it shows you what Google itself concluded about your site, which no third-party crawler can replicate, because a crawler doesn’t have access to Google’s actual index or its actual manual-action list. That’s the ten checks below. Each one reads a number Google computed, not a number a crawler estimated.

The step-by-step audit guide

Run these in order. The first two are veto checks — if either fails, stop and fix it before spending time on anything else below, because a manual action or a security flag can suppress your entire site regardless of how clean the rest of this checklist comes back.

1. Manual actions and security issues
2. Page indexing (the Pages report)
3. URL Inspection on your priority pages
4. Canonicals — user-declared versus Google-selected
5. The Sitemaps report
6. Core Web Vitals
7. The Performance report — clicks, impressions, CTR, position
8. Discover, if it applies to your site
9. The Links report, read as a sanity check
10. The Removals tool

Step 1: Manual actions and security issues

Open Security & Manual Actions in the left-hand menu. Both reports are binary: a clean site shows a green check mark and an explicit “no issues detected” message; anything else is a fail. A single manual action means a human reviewer at Google determined that pages on your site did not comply with its spam policies, and it can suppress rankings for the affected URL pattern — sometimes your entire site — without any visible signal to a visitor. The Security Issues report works the same way for hacked content, malware, and deceptive pages.

Threshold: zero tolerance. One listed manual action or security issue outranks every other item on this list. Fix and file a reconsideration request before you spend another minute on indexing or Core Web Vitals — those checks are meaningless while a manual action is active.

Step 2: Page indexing (the Pages report)

Open Indexing > Pages. This is the report most audits open first, but the number worth reading is not the raw indexed count — it’s what share of your important URLs sit in Discovered – currently not indexed or Crawled – currently not indexed, the two statuses that mean Google found the URL and chose not to index it yet, as opposed to a status like a noindex tag or a robots.txt block, which mean you told it not to.

Google’s own guidance is to check that your important pages are indexed and that the ones that aren’t have a reason you’d expect — a duplicate, an intentional noindex, a page you’ve removed. The Page indexing report samples up to 1,000 example URLs per status and is not guaranteed to show every URL even below that cap, so treat the example list as a sample to spot-check, not a full export.

Threshold: any page you’d want to rank showing “not indexed” for an unexplained reason is a fail. A content site where “Crawled – currently not indexed” covers more than 10 percent of URLs that should matter is worth a deeper look — that status usually means Google visited the page and judged it not worth indexing, which is a content or duplication signal, not a technical error to route around.

Step 3: URL Inspection on your priority pages

The Pages report tells you about your site in aggregate; the URL Inspection tool tells you about one URL specifically. Run it against your homepage and your five to ten highest-value pages — the ones actually driving revenue or leads — rather than trying to inspect your whole site one URL at a time.

Read three fields: Page fetch (Successful, Failed with a reason, or N/A), Crawl allowed? (whether robots.txt blocked Googlebot), and Indexing allowed? (whether a noindex directive is present). A failed fetch will list a reason such as a DNS resolution failure, an HTTP server error, or a redirect chain that never resolved — different problems that need different fixes, which is why the generic “not indexed” status in step two is not enough on its own for a page that matters.

Threshold: any priority page returning anything other than “Successful” plus “indexed” is a fail worth fixing this week, not queuing for later. If the live test and the indexed version disagree, that’s also worth noting — it usually means something changed on the page since Google’s last crawl.

Step 4: Canonicals — user-declared versus Google-selected

Still inside URL Inspection, check the User-declared canonical and Google-selected canonical fields for the same set of priority pages. These match on a healthy site. When they don’t, Google decided a different URL was the authoritative version of the content than the one you specified — often because of thin duplication, a parameter variant, or an HTTP-versus-HTTPS mismatch it treated as more authoritative.

Threshold: any priority page where Google’s selected canonical is not the URL you’d want ranking is a fail. It means the URL you’re building links to, tracking in analytics, and sharing is not necessarily the one showing up in Search — a quiet mismatch that a crawl-based audit won’t catch, because it requires Google’s own index data, not a technical scan of your HTML.

Step 5: The Sitemaps report

Open Indexing > Sitemaps. Each submitted sitemap shows the status of Google’s last request for it: fetched and read without errors, unable to be fetched at all, or fetched with some number of errors inside it. This is a small check, but it’s the one that silently breaks discovery for an entire section of a site when a build process starts generating a malformed or empty sitemap and nobody notices for months.

Threshold: anything other than a clean, error-free fetch is a fail. A sitemap Google can’t fetch is usually a DNS, HTTP status, or file-format problem on your end, not a Google-side issue — check the URL resolves with a normal HTTP request before assuming Google is at fault.

Step 6: Core Web Vitals

Open Experience > Core Web Vitals. This is the step most audit guides tell you to “fix” without ever naming a number — here are the actual ones. Google groups pages into URL groups by template and reports the share in each bucket for three metrics: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).

The published thresholds, per Google’s own Web Vitals documentation, are:

• LCP: good at 2.5 seconds or faster; poor past 4 seconds
• INP: good at 200 milliseconds or faster; poor past 500 milliseconds
• CLS: good at a score of 0.1 or lower; poor past 0.25

Threshold: a URL group with any meaningful share of pages in the “poor” bucket for any one of the three metrics is a fail, and it’s worth fixing before content-level work, because Core Web Vitals is one of the few audit items here with a direct, documented tie to ranking eligibility for the page experience signal. A group sitting in “needs improvement” isn’t urgent, but it’s the next thing to schedule once “poor” is clear.

Step 7: The Performance report — clicks, impressions, CTR, position

Open the Performance report and filter to Search results. Look at click-through rate (CTR) against position for your top queries and pages, and watch for organic traffic drops that line up with a specific date rather than drifting slowly — a sharp single-day drop usually means an indexing or manual-action problem you’d already have caught in steps one and two; a slow multi-week decline usually means a rankings or content problem instead.

Two documented limits shape how you should read this report. The interface table shows a maximum of 1,000 rows, and the Search Analytics API returns up to 25,000 rows per request by default (up to 50,000 rows a day per site and search type with pagination) — either way, low-volume queries below Google’s privacy threshold are anonymized and omitted from the table entirely, though they’re still counted in the report’s totals. Both limits and the anonymization behavior are documented in Google’s own Performance report deep dive.

Threshold: a CTR meaningfully below what similar positions typically get, for a query you already rank well on, is worth a title-and-description rewrite. There’s no single universal CTR benchmark Google publishes per position — the useful comparison is your own page against your own site’s other pages at a similar position, not an outside benchmark.

Step 8: Discover, if it applies to your site

If your site publishes content that could plausibly surface on mobile feeds, check the Discover report for impressions, clicks, and CTR trends. Discover is a separate surface from Search results — it uses different signals, has no query data attached to it (Google doesn’t tell you what triggered a Discover impression), and can send meaningful traffic to sites that barely show up in this report at all.

Threshold: this step is conditional, not universal. If Discover shows zero data, that’s expected for most transactional or B2B software content and not a problem to chase. If it shows a sharp, sustained drop for a site that previously had real Discover traffic, treat it the same as a Search traffic drop in step seven — check for a content-quality or policy issue rather than a technical one, since Discover eligibility leans more heavily on content signals than crawl or indexing signals.

Step 9: The Links report, read as a sanity check

Open Links and skim Top linking sites and Top linked pages. Read this for one thing only: whether a spammy or unfamiliar domain sits near the top of your linking sites, which can be an early signal of a negative-SEO attempt or a scraped-content problem worth investigating further.

Do not read this report as a backlink audit. It shows links Google has found over time, some of which may since have been removed, with no domain authority metric, no historical trend chart, and no way to see a competitor’s link profile — that’s a materially different job than the one this report does, and it’s outside what Search Console, or any tool built on top of it, is designed to answer.

Threshold: a genuinely unfamiliar or clearly spammy domain among your top linking sites is worth investigating. Anything else here is informational, not a pass or fail line.

Step 10: The Removals tool

Open Removals and check the history of temporary removal requests, which Search Console keeps for the past six months. This step catches a specific, easy-to-forget failure mode: someone filed a temporary removal on a URL months ago for a since-resolved reason, and it’s still suppressing a page that should be back in Search results.

Threshold: any active temporary removal on a URL you’d want indexed today is a fail. It’s rare, but when it happens it’s invisible everywhere else in this checklist — the Pages report and URL Inspection tool both need to be read alongside this one to catch it.

Thresholds at a glance

Check	Where	Fails when
Manual actions / security	Security & Manual Actions	Any item listed
Page indexing	Indexing > Pages	Priority URL not indexed for an unexplained reason
URL Inspection	URL Inspection tool	Page fetch not “Successful,” or indexing blocked
Canonicals	URL Inspection tool	Google-selected canonical differs from your intended URL
Sitemaps	Indexing > Sitemaps	Status other than a clean, error-free fetch
Core Web Vitals	Experience > Core Web Vitals	Meaningful share of a URL group in “poor” for LCP, INP, or CLS
Performance	Performance report	CTR below your own comparable-position baseline
Discover	Performance > Discover	Sharp, sustained drop on a site with prior Discover traffic
Links	Links report	Spammy or unfamiliar domain among top linking sites
Removals	Removals tool	Active temporary removal on a wanted URL

Practical tips for turning findings into an action list

Fix in the order you audited, not the order you found things. Steps one and two can invalidate everything below them — a page suppressed by a manual action doesn’t need a Core Web Vitals fix yet, and an unindexed page doesn’t need a canonical check yet, because neither will show up in Search regardless of what you do to it.

Separate technical fails from content fails. A failed page fetch, a bad sitemap, and a blocked-by-robots.txt issue are engineering tickets. A “Crawled – currently not indexed” status on a thin or duplicate page is a content or consolidation decision, and it needs an editorial call, not a deploy.

Re-run URL Inspection after every fix, not just once. A live test result reflects the current state of a page immediately; the indexed version only updates after Google recrawls it, which can take anywhere from hours to weeks depending on how often Googlebot visits that section of your site. Treat the live test as your “did I fix it” check and the indexed version as your “did Google notice” check — they answer different questions.

Keep a dated log of what you found and what you changed. Google’s algorithms and its own report definitions shift often enough that a threshold worth flagging in one quarter can be normal by the next, and having a record of what a metric looked like before a fix is the only way to tell whether the fix actually worked or the number moved for an unrelated reason.

Set a recurring cadence, not a one-time pass. Manual actions and indexing status are worth a weekly glance; Core Web Vitals and the Performance report are usually a monthly check, since both take real traffic volume and page-experience data to move meaningfully.

Where Search Console runs out

Two specific steps above hit a wall that isn’t about effort — it’s a documented limit of the free tool itself. A free Looker Studio build can chart the same Search Console data more usefully than the default UI, but it inherits the same 16-month and 1,000-row ceilings underneath — it’s a better view of the data Search Console gives you, not more of it. The Performance report retains data for 16 months, which is enough for the year-over-year comparison most of this checklist needs, but not enough to see what your site looked like three years ago before a migration or a redesign. And the report’s own interface table caps out at 1,000 rows — fine for a small site’s query list, thin for a site with tens of thousands of indexed pages where the queries and pages that matter can sit well past row 1,000.

SEO Gets Core — Search Console and GA4 in one view

Core is the first paid tier, listed at $39 per month, and the thing it changes is that search data and behaviour data stop living in two separate tabs. It connects Google Analytics 4 alongside Search Console, then layers on the reports that are tedious to reproduce by hand: striking distance, keyword cannibalization, and content decay. The client-facing half is what most agencies actually buy it for — live portals shared by link, scheduled reports that send themselves, and PNG export carrying your own branding rather than a vendor logo.

What to check

• Vendor: SEO Gets
• Plan level: first paid tier, above the free plan and below Pro
• Check before buying: whether you specifically need GA4 alongside Search Console, whether anyone will actually open the client portals, and whether the opportunity reports tell you something your current process does not

Who it suits

The reader who has outgrown exporting Search Console by hand every month but has not yet hit the retention wall. That is usually a freelancer or a small agency reporting on several client properties, where the saving is measured in hours per client per month rather than in any single feature. Connected properties and team seats are unlimited on every tier including Free, so this plan is not a way to buy more capacity — it is a way to buy the reports and the client-facing output.

Be aware

History stays at 16 months on this tier, matching Search Console’s own limit, so if the problem you are solving is a year-over-year comparison that already aged out, this plan does not solve it. Index reporting for indexed pages is a Pro capability and is not included here either. And the free plan is a genuinely working Search Console dashboard, so the honest question before paying is whether GA4, the client portals or the opportunity reports are worth $39 a month to you specifically — not whether the paid tier is better in the abstract.

See best price

SEO Gets Pro — the tier that removes Search Console’s ceilings

Pro is listed at $49 per month and exists to lift the two limits that eventually stop everyone: Google Search Console retains 16 months of performance data and throttles its API, and no dashboard built on top of it can invent history the source no longer holds. This tier retains up to five years, removes the Search Console API request limit, and adds index reporting so the number of pages Google actually has indexed becomes something you can watch move rather than something you spot-check. It also introduces the Super Site concept, extended storage, and content change tracking.

What to check

• Vendor: SEO Gets
• Plan level: top tier, above Core
• Check before buying: how old the site is, how many properties genuinely need long history, and whether anyone will act on index reporting once they have it

Who it suits

The reader whose reporting question is historical — year-over-year comparisons, the shape of a site before and after a core update, or an argument that has to be made with data older than Search Console keeps. It also suits anyone whose current setup is already hitting Search Console API quota errors rather than row limits, because removing that ceiling is a capability rather than a convenience.

Be aware

The extended history and index reporting apply to one Super Site, so a portfolio of equally important properties is a different calculation than a single flagship site, and it is worth doing that arithmetic before upgrading. Retention also only runs forward: a plan bought today does not retroactively recover months that have already aged out of Search Console, which is the single most common misunderstanding about paying for retention. If the site is younger than 16 months, the headline feature has nothing to retain yet and Core is the honest recommendation.

See best price

Both plans connect directly to your existing Search Console and GA4 properties and turn the same underlying data into a dashboard you don’t have to rebuild by hand — Core adds GA4 alongside Search Console, client-facing report output, and an Opportunity Report that surfaces striking-distance keywords instead of you scanning 1,000 rows for them manually. Pro is specifically the plan that lifts the two limits this section is about: it retains up to five years of history instead of 16 months, and it adds index reporting — a running count of indexed pages over time, which is closer to a trend line than the single-moment snapshot the Pages report in step two gives you.

Neither plan changes what step one through ten are checking. They’re still reading the same Search Console and GA4 data — a paid dashboard doesn’t see more of your site than Search Console does, it just keeps more of the history and clears the row cap that step seven runs into on a large site. If your site is younger than 16 months or you’re only checking one property, that ceiling hasn’t been reached yet, and there’s no reason to pay to extend a window you haven’t hit the edge of.

Who this checklist fits

• Agencies auditing a new client’s site before a proposal → the full ten steps, in order, are a fast way to find what’s actually broken before you commit to a scope of work. Steps one and two alone catch the failures that make every other recommendation pointless.
• In-house SEO leads running a quarterly health check → steps six through nine matter most on a recurring basis; steps one, two, and five are worth a lighter, more frequent glance since they can break silently between quarters.
• Site owners who have outgrown checking Search Console by memory → the Thresholds at a glance table above is the version worth bookmarking — it’s the whole checklist compressed to one pass at a glance.
• Anyone managing more than a handful of properties → the audit itself doesn’t change, but running it by hand across five or ten sites is where the 1,000-row and 16-month limits start costing real time, which is the point where a master dashboard starts paying for itself instead of a spreadsheet.
• Anyone still deciding between this checklist and a broader tool stack → this audit only covers what Search Console itself can see; a best SEO monitoring tools comparison is the place to check whether your real gap is rank tracking, crawling, or backlinks instead.

Frequently asked questions

How long does this audit actually take?

For one site with URL Inspection already run on your priority pages, expect 30 to 60 minutes for the full ten steps — most of the time is reading, not fixing. Steps one, two, five, and ten are quick binary checks; steps three, four, six, and seven take longer because you’re reading numbers against a specific set of pages rather than a single site-wide status.

Do I need to run every step, or can I skip ones that don’t apply?

Step eight, Discover, genuinely doesn’t apply to every site — skip it if your content type wouldn’t reasonably surface there. Steps one and two apply to every site with no exception, since they’re the veto checks. The rest are worth at least a quick pass even on a small site, because several of them — canonicals and sitemap errors especially — fail silently with no visible symptom until traffic has already dropped.

What’s the difference between “Discovered – currently not indexed” and “Crawled – currently not indexed”?

“Discovered” means Google knows the URL exists — usually from a sitemap or an internal link — but hasn’t crawled it yet, often simply due to crawl budget or timing. “Crawled” means Google fetched the page and then chose not to index it, which is a stronger signal about content quality, thinness, or duplication rather than a scheduling delay. A URL moving from the first status to the second, and staying there, is worth more attention than one still waiting to be crawled for the first time.

Does Core Web Vitals actually affect my Search rankings, or is it a minor signal?

Google has confirmed page experience, including Core Web Vitals, is one of many ranking signals, and it becomes a more meaningful tiebreaker between pages that are otherwise similarly relevant to a query — it is not typically the reason a page fails to rank at all. That said, a page in the “poor” bucket is also usually a worse experience for a real visitor regardless of what it does to rankings, which is reason enough to fix it.

My Performance report numbers don’t match what a paid rank tracker shows for the same keyword. Which one is right?

Neither is “wrong” — they’re measuring different things. Search Console’s average position reflects Google’s own calculation across every impression it recorded for that query, blending devices, locations, and result types. A rank tracker runs its own simulated search from one location and device combination on a schedule and logs a single position for that specific check. Expect them to disagree, sometimes by several positions, without either tool having an error.

Can Search Console tell me if a competitor is outranking me for the same audit checks?

No. Every report in this checklist covers your own verified properties only — Search Console has no visibility into another site’s indexing status, Core Web Vitals scores, or manual actions, and there’s no way to inspect a URL you don’t own through the standard URL Inspection tool. Comparing your own numbers against a competitor’s requires a third-party tool that independently crawls or ranks-tracks both sites, which is outside what Search Console does at any price.

How often should I re-run this audit?

A full pass once a quarter catches most drift before it costs meaningful traffic. Steps one, two, and five are cheap enough to check monthly or even weekly once you know where to look, since a manual action or a broken sitemap can appear between quarterly passes and sit unnoticed the whole time.

Running this checklist once tells you where you stand today; running it on a schedule is what actually protects the traffic it’s meant to catch problems in. If your next question is where that data should live day to day, an SEO monitoring dashboard and a proper SEO reporting dashboard cover the reporting side of this in more depth than fits here. For the free, DIY route past the same 1,000-row and 16-month limits this article flags, the Search Console API and BigQuery bulk export are the two places to look next. If you’re still working out which numbers are worth tracking between audits, SEO KPIs is worth reading before the next quarterly pass. And if you’re building a checklist like this one into a recurring client deliverable, SEO client reporting and the SEO report template guide are the natural next stop.