Key takeaways
- An SEO analysis audit should answer three questions: can Google reach the pages, does it index the right ones, and do they deserve to rank.
- Google says you should “not expect all URLs on your site to be indexed, only the canonical pages”, so the Page indexing report is read for important pages, not for a zero count.
- The URL Inspection tool shows Google’s stored version of a page; “This is not a live test” unless you run one.
- For page experience, web.dev sets “good” at an LCP within 2.5 seconds, an INP of 200 milliseconds or less and a CLS of 0.1 or less.
- The audit is only finished when every finding has a fix, an owner and a priority.
An SEO analysis audit is a structured look at why a site ranks the way it does, and what to change first. It is the starting point for most technical SEO work I do, and the method is the same whether the site has fifty pages or fifty thousand.
I have worked in SEO and digital marketing for more than 16 years, and over that time my audits have become shorter, not longer. The tools find hundreds of warnings on any site. The skill is in deciding which ten matter. This article walks through the steps I follow, in order, using mostly free Google tools, so you can run a first pass yourself.
If you are buying an audit rather than running one, read what a paid SEO audit should deliver instead; this article is the do-it-yourself view of the same work.
What an SEO analysis audit should answer
Before opening any tool, write down the question. “Do an audit” produces a long PDF. “Why did our service pages lose clicks since spring?” produces a fix. Most audits I run come back to three questions:
- Can Google reach the pages? Crawling, status codes, redirects, internal links.
- Does Google index the right pages? Canonicals, noindex, duplicates, thin pages.
- Do the indexed pages deserve to rank? Content, intent, page experience and links.
The steps below follow that order on purpose. There is no point polishing content on a page Google has never indexed, and no point chasing links to a page that redirects twice.
| Step | Main question | Main tool |
|---|---|---|
| 1. Crawl | Can every important page be reached? | A crawler, your sitemap |
| 2. Indexing | Are the right pages in Google’s index? | Page indexing report, URL Inspection |
| 3. Performance | Which pages and queries win or lose clicks? | Search Console Performance report |
| 4. Content | Does each page match what searchers want? | Your eyes, the search results |
| 5. Internal links | Do links point to the pages that matter? | Crawl data |
| 6. Page experience | Is the site fast and stable for real users? | Core Web Vitals report, PageSpeed Insights |
| 7. Links and priorities | What is worth fixing first? | Links report, your judgement |
Step 1: Crawl the site the way a search engine would
A crawler follows links from your homepage, much as a search engine does, and lists every URL it finds with its status code, title, canonical tag and indexing directives. I compare that list with the XML sitemap. Pages in the sitemap but not found by the crawl are orphans; pages found by the crawl but missing from the sitemap are often duplicates or old URLs.
What I look for in the crawl:
- Status codes: internal links that point to 404 pages or to redirects, and redirect chains of more than one hop.
- Duplicates: the same content on several URLs (with and without a trailing slash, with tracking parameters, HTTP and HTTPS).
- Directives: important pages with a noindex tag or a canonical pointing somewhere else by mistake.
- Links Google can follow: Google’s guide to crawlable links says “Generally, Google can only crawl your link if it’s an HTML element (also known as anchor element) with an href attribute”. Menus built from buttons or scripts can hide whole sections.
The same guide says: “Every page you care about should have a link from at least one other page on your site.” An orphan page breaks that rule, however good it is.
Step 2: Check indexing in Search Console
Next I compare what I found with what Google says. The Page indexing report “shows how many URLs on your site have been crawled and indexed by Google”, with the reasons for pages that were not.
People often panic at a large “not indexed” number. Google’s own help page is calm about it: “You should not expect all URLs on your site to be indexed, only the canonical pages.” And: “Your goal is to get the canonical version of every important page indexed.” So I filter for the pages that matter and read the reasons:
| Reason in the report | What Google says it means | What I check |
|---|---|---|
| Crawled, currently not indexed | “The page was crawled by Google but not indexed.” | Is the page thin, duplicated or unhelpful? |
| Discovered, currently not indexed | “The page was found by Google, but not crawled yet.” | Internal links to it, site speed, number of low-value URLs |
| Duplicate without user-selected canonical | A duplicate that doesn’t name a preferred page | Add a canonical, or merge the pages |
| Alternate page with proper canonical tag | Correctly points to the canonical | Usually nothing |
| URL marked “noindex” | Google found a noindex directive | Was it meant to be there? |
For individual pages I use the URL Inspection tool. It shows the Google-selected canonical next to the one you declared, which is the quickest way to spot Google ignoring your canonical. Two details catch people out. The default view is Google’s stored version: “This is not a live test.” And a rendered screenshot is available only in a live test, which is what you need to see whether JavaScript content appears for Google.
Step 3: Read the Performance report for patterns
The Search Console Performance report shows clicks, impressions, click-through rate and average position. Its definitions are worth reading once. Average position, for example, is “The average position of the topmost result from your site”, and the chart value covers the whole site, which is why it rarely matches a single keyword check. We explain the difference in Search Console average position vs a rank tracker.
I compare the last three months with the same period a year earlier, then sort pages by the change in clicks. Three patterns come up again and again:
- Pages losing impressions: Google shows them less. Often a content, intent or indexing problem.
- Pages with impressions but few clicks: they appear but don’t attract the click. Often a title and snippet problem, or a results page full of other features.
- Queries landing on the wrong page: two pages compete for the same search, and neither wins clearly.
If traffic has fallen overall, the causes I check in order are in why organic traffic is decreasing.
An audit is not a list of everything wrong with a site; it is a short list of what is holding the important pages back.
Step 4: Check content against search intent
Now I read the important pages the way a searcher would, with the search results open in another tab. Does the page answer the question better than what already ranks? Is it clear who wrote it and why they know? Is it the right type of page: a guide where people want a guide, a service page where people want to hire?
The most common problems I find are not about missing keywords. They are pages that try to serve two intents at once, several thin pages that should be one strong page, and old posts that still rank but give outdated answers. Each finding goes in the audit with a specific action: rewrite, merge and redirect, update, or leave alone.
Step 5: Internal links that point to the right pages
Internal links tell both visitors and search engines which pages matter. From the crawl data I list each important page with the number of internal links pointing to it and the anchor text used.
Typical fixes: link service pages from the blog posts that discuss the same topic, replace “read more” anchors with descriptive ones (Google’s guide says “Good anchor text is descriptive, reasonably concise, and relevant to the page that it’s on and to the page it links to”), and remove links to redirected URLs. It is one of the cheapest fixes in any audit and, in my experience, one of the most often skipped.
Step 6: Page experience and Core Web Vitals
I check the Core Web Vitals report in Search Console first, then test sample templates in PageSpeed Insights. The “good” thresholds come from web.dev’s guide to Web Vitals:
| Metric | What it measures | Good, according to web.dev |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading | Within 2.5 seconds |
| Interaction to Next Paint (INP) | Responsiveness | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Visual stability | 0.1 or less |
web.dev says “a good threshold to measure is the 75th percentile of page loads”, split by mobile and desktop. I audit templates, not single URLs: if the product template is slow, every product page is slow, and one fix helps all of them. On WordPress sites, the 15 technical fixes in priority order cover most of what I find here.
Step 7: Links, then a priority list
Last, I look at links from other sites in Search Console’s Links report: which pages earn links, whether any of them now return errors or redirect badly, and whether the important pages have any external support at all. Link work is slow, so in an audit it is mostly about not wasting what you already have.
Then comes the step that makes the audit useful: turning findings into a short, ordered plan.
Every finding in the final audit should have
- The evidence: a URL, a screenshot or a report filter someone else can repeat.
- The fix: written so a developer or editor can act on it without a meeting.
- The impact: which important pages it affects, and why it matters for them.
- The effort: a rough size (small, medium, large), agreed with whoever will do it.
- An owner and a date, plus a note on how you will check the result.
I usually end with no more than ten priorities. The rest go in an appendix. If the list is longer than the team can deliver in a quarter, it is not a plan, it is a backlog.
When to run the audit yourself and when to get help
A first pass through these steps is within reach of anyone comfortable with Search Console. Where it gets harder is interpretation: why Google chose a different canonical, whether a traffic drop is a site problem or a change in the results page, and which fix to do first when the developers have little time. That is the part I spend most of my own audits on, and what I described in what I look at in the first hour as a technical SEO consultant. If you want a second pair of eyes on your findings, an SEO website audit can start from the work you have already done.
FAQ
How long does an SEO analysis audit take?
It depends on the size of the site, the number of templates and how much access you have. A small site can get a useful first pass fairly quickly; large sites with many templates take longer. The time goes mostly into checking findings and writing clear fixes, not into running tools.
Can I do an SEO audit with only free Google tools?
Mostly, yes. Search Console covers indexing, performance, Core Web Vitals and links, and PageSpeed Insights tests individual pages. A crawler adds the full list of URLs and internal links, which Search Console doesn’t give you in one place.
Should I request indexing for every page I fix?
No. The URL Inspection tool lets you request indexing for single URLs, but Google says “Submitting a request does not guarantee that the page will appear in the Google Index,” and requests have daily limits. For many pages, a sitemap is the recommended route.
How often should a site be audited?
A full audit makes sense before and after a redesign or migration, and when traffic changes without an obvious reason. In between, a monthly look at the Page indexing and Performance reports catches most problems early.
If you have run your own audit and want help deciding which fixes come first, send me your findings and I'll tell you where I would start.
Eugen Platon · SEO consultant with 16+ years in SEO and digital marketing · free 10-minute first call