What a technical SEO audit should tell you, and what to fix first

A technical SEO audit should tell you whether search engines can crawl, render and index the pages that matter to your business, what's stopping the ones that can't, and what to fix first. A useful audit ends with a short list ranked by impact on the pages that bring in revenue, with evidence and a definition of done for each item, not a spreadsheet of every warning a crawler found.

Most audits get the first part right and skip the second. Here's what a good one should cover, and how I decide what goes to the top of the list.

The questions an audit should answer

Before any checklist, an audit should answer a handful of plain questions about your site:

1. Can search engines find the pages you care about?
2. Are those pages indexed, and if not, why not?
3. Is Google choosing the URL you want for each page, or a duplicate?
4. Do your pages render and load properly for people and for crawlers?
5. Does your site structure make it clear which pages matter most?
6. Is your structured data valid and accurate?
7. Did something change recently, like a release, a redesign or a CMS move, that lines up with a drop?

If an audit can't answer each of these in a few sentences, it's a list of symptoms, not a diagnosis.

What a good audit checks

Crawling

I crawl the site the way a search engine would and look at status codes, redirect chains, broken internal links, orphan pages that nothing links to, and URL patterns that create endless variations, like filters and tracking parameters.

I also check robots.txt. It controls what crawlers can request, but Google is clear that robots.txt isn't a way to keep a page out of Google. A blocked page can still be indexed if other pages link to it. Crawl budget gets a lot of attention, but Google's crawl budget guide is written for very large or fast-changing sites. For most sites, crawl problems come from structure: important pages buried deep, or crawlers spending time on URLs that shouldn't exist.

Indexing

This is where an audit earns its fee. I compare the crawl with the page indexing report in Google Search Console, which shows which URLs Google has indexed and why it left others out. "Crawled - currently not indexed" means Google fetched the page and chose not to index it. "Discovered - currently not indexed" means Google knows the URL exists but hasn't crawled it yet. They point to different problems and different fixes.

I also look for noindex tags left over from a staging site, a launch mistake I check for on every audit. Google's documentation on blocking indexing with noindex includes an important catch: Google has to be able to crawl the page to see the tag at all.

Canonicals and duplicates

When several URLs show the same content, Google picks one as the canonical and mostly ignores the rest. Your canonical tag is a strong hint, not an order. The URL Inspection tool in Search Console shows both the canonical you declared and the one Google selected. When they disagree on important pages, your internal links, sitemap or redirects are sending mixed signals. Google's guide to consolidating duplicate URLs explains which signals it weighs.

Sitemaps

A sitemap should list only the URLs you want indexed: canonical, returning a 200 status, and not blocked or set to noindex. Google says it ignores the priority and changefreq values and uses lastmod only when it's consistently accurate. A sitemap that stamps today's date on every URL wastes the one field that helps.

Rendering and speed

If your content or links only appear after JavaScript runs, I check that Google can render them. Google's JavaScript SEO basics explain how that rendering works. For speed, I review Core Web Vitals on your key templates: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Checking templates rather than every URL finds the fix that improves every page built from them.

Internal links and structure

Important pages should be linked from your navigation, hub pages and related content, and sit a few clicks from the homepage. Those links need to be standard HTML links with an href that crawlers can follow, as Google explains in its guide to crawlable links. Menus and buttons that only work through JavaScript click handlers are a common miss.

Structured data

I check the schema on each page type: whether it validates, whether it matches what's visible on the page, and whether it's the right type for the page. Google's structured data guidelines require markup to describe the page's actual content. If the schema came from a plugin and nobody has looked at it since, this is usually where I find problems. When the fix is bigger than a few tweaks, it becomes a separate schema markup project.

How to prioritize the fixes

Every finding gets two scores: impact and effort.

• Impact is how many important pages the issue affects, and how badly. A noindex tag on your pricing page is severe. A meta description a few characters too long is not.
• Effort is developer time, risk and who needs to be involved. A robots.txt edit takes minutes. Changing how a JavaScript framework renders your navigation can take a full sprint.

With those two scores, findings fall into four groups:

1. Fix now. Anything keeping revenue pages out of the index or pointing Google at the wrong URL: stray noindex tags, robots.txt blocks on sections that matter, canonicals pointing to the wrong page, broken redirects on URLs with traffic or links, and server errors.
2. Fix next. Template-level problems that affect many pages: slow loading on a key template, links that only work with JavaScript, duplicate titles generated by the CMS, and filter URLs getting crawled and indexed.
3. Schedule. Structural improvements that pay off over time: internal links between related pages, sitemap cleanup, and schema across every page type.
4. Batch or skip. Low-impact warnings that tools flag loudly, like title lengths a few characters over a guideline. Group them into routine maintenance, or leave them alone.

Two rules help with the order inside each group. Fix at the template level whenever you can, because one change fixes every page built on that template. And fix whatever blocks other fixes first. There's no point tuning internal links into a section Google can't crawl.

What each item on the fix list should include

A fix list is only useful if the person making the fix can act on it without a meeting. Every item in my audits includes:

• The issue, in plain language
• The affected template or URLs, with examples
• The evidence: crawl data, Search Console screenshots or test results
• Why it matters, and for which pages
• The fix, written for whoever will make it
• A definition of done, so everyone knows how to check it worked
• A priority and a suggested owner

Red flags in an audit you've been sent

• A health score with no explanation of what drives it.
• Hundreds of issues, all given the same weight.
• No reference to Search Console data, only a crawler's view of the site.
• No sense of which pages earn traffic or revenue.
• Recommendations that don't say who should do what.
• A conclusion that amounts to "fix everything".

After the fixes

Check the work. I recrawl the affected sections, run URL Inspection on key pages, and watch the page indexing report as Google recrawls. None of this is instant. Google has to revisit the pages before its index reflects the change, so give it time before you judge the result.

Then stop it from breaking again. Technical problems usually arrive with a release, a redesign or a platform move. Before a site I work on goes live, I run my Playwright QA suite against the staging site to check links, images, SEO meta tags, redirects, accessibility and forms. If a redesign or replatform is coming, plan an SEO-safe migration while the new URLs are still on paper, not after launch.

Where to start

Open the page indexing report in Search Console and look at the pages that aren't indexed. If you see pages there that should be earning traffic, or you can't tell why they're excluded, that's the place to begin. My technical SEO audit is fixed in scope and ends with a ranked fix list your developers can work through. Get in touch and tell me what you're seeing.