A technical SEO audit is a structured review of whether search engines can crawl, render and index your site, and how to do a technical SEO audit comes down to six steps. Scope the job, collect data from Search Console, a site crawl, Chrome UX Report field data and (if you can get them) server logs. Then analyze the findings in a fixed order: indexability, crawlability, canonicals and duplicates, rendering, speed, structured data and international setup. Score every finding by impact and effort, write it up as a short report with owners, and re-check after the fixes ship.
That’s the technical SEO audit process I follow. This post is about the method, not the list of things to check. The checks themselves live in my technical SEO checklist, the full site-wide list is my SEO audit checklist, and the symptom-to-fix guide is common technical SEO issues. Keep one of those open while you work through the steps below.
What Shapes the Audit Before You Start?
Four variables change how long a technical audit takes and where the hours go. I write them down on the first page of my notes, because they decide which steps get an hour and which get a day.
- Site size. Under a few thousand URLs, a desktop crawler and Search Console cover almost everything. Once you’re into hundreds of thousands, crawl efficiency becomes a real topic and logs start to matter.
- How pages are built. A WordPress or Shopify site sends finished HTML. A JavaScript app may not, which pushes rendering up the list.
- Languages and regions. One language and one market means you skip the international step entirely.
- What access you have. Search Console owner access, a CMS login and server logs are three different levels of evidence. No logs is fine. No Search Console is a problem.
Step 1: Scope the Audit in One Page
Most audits fail before a single tool runs. Someone crawls everything, exports 40 tabs and hands over a spreadsheet nobody reads. I avoid that by writing a one-page scope first.
The scope answers five questions. What triggered the audit (a traffic drop, a migration, a new owner, a routine check)? Which hosts are in scope, including subdomains like shop. or blog.? Which page templates exist, such as home, category, product, post and location? Which pages earn the money? And who will fix things, a developer, an agency or the owner on a Saturday?
The template list matters more than people expect. When I audit a store, the product template alone usually explains most of what I find. Technical problems almost always live in templates, not single pages. If I know a site has seven templates, I know I’m really auditing seven things, and every finding gets traced back to one of them.
If the audit was triggered by a sudden drop, then add the exact date to the scope and compare it against deploys, plugin updates and Google’s update announcements. If it’s a routine audit, then skip that and set a baseline instead: indexed pages, crawl requests per day and Core Web Vitals status, so the next audit has something to compare against.
Step 2: Collect Data From Four Sources
I collect everything before I analyze anything. Mixing the two is how you end up fixing the first scary thing you see instead of the most important one.
Search Console. Export the Page indexing report, the Sitemaps report, the robots.txt report and Crawl stats (under Settings), plus Core Web Vitals, HTTPS, Manual actions and Security issues. Then run URL Inspection on one URL per template. That gives you Google’s own view of crawling and indexing, which no third-party tool can fully reproduce. Note that Google’s Crawl Stats help page says the report covers the past 90 days and only works on root-level properties.
A crawler. Crawl the site the way a bot would, starting from the homepage. Screaming Frog’s SEO Spider is the tool I reach for, and its official page lists a 500-URL limit on the free version. Feed it the XML sitemap as well, so you can compare what’s linked against what’s listed.
Field speed data. PageSpeed Insights shows Chrome UX Report data for real users, and Google’s PSI documentation says that data covers a trailing 28-day period and is reported at the 75th percentile. Lab scores are useful for debugging. Field data is what you report.
Server logs, if available. Logs show what Googlebot actually requested, not what you hope it requested. Before trusting any log line, verify the bot. Google’s guide to verifying Google’s crawlers describes a reverse DNS lookup that should resolve to googlebot.com, google.com or googleusercontent.com, or a match against its published IP range files. Fake Googlebots are common, and they’ll skew your numbers badly.
| Source | What it answers | Needed for |
|---|---|---|
| Search Console | What Google indexed, excluded and crawled | Every audit |
| Crawler | What a bot can reach by following links | Every audit |
| CrUX / PageSpeed Insights | How fast pages are for real users | Every audit |
| Server logs | Where Googlebot spends its requests | Large or fast-changing sites |
Step 3: Analyze in a Fixed Order
Order matters because each layer depends on the one before it. There’s no point tuning schema on a page that isn’t indexed. I work through seven layers, and I don’t move on until I understand the current one.
1. Indexability
Start with the Page indexing report and sort the “Why pages aren’t indexed” reasons by count. Then filter to your money templates. The question isn’t “are there excluded pages?” because every site has them. It’s “are pages I need sitting in the wrong bucket?”
If a template you care about shows up under noindex or a soft 404, then that’s a top finding, stop and trace it to its cause. If the excluded URLs are tag archives, feeds or filter pages, then note it and move on.
2. Crawlability
Next, check whether Google can reach what it should. Read the robots.txt file line by line, compare the crawl against the sitemap and look at Crawl stats for spikes in server errors or response time. My robots.txt guide covers the rules and the mistakes I see most.
Orphan pages show up here too. Anything in the sitemap that your crawl never reached has no internal links pointing at it. On large sites, this is also where logs earn their keep, and my post on crawl budget explains when that’s worth worrying about.
3. Canonicals and Duplicates
Compare the canonical each template declares with the canonical Google selected in URL Inspection. Then look at parameter URLs, trailing slashes, http and https and www variants. When signals disagree (canonical tag says one URL, internal links and sitemap say another), Google picks for you.
4. Rendering
Run a live test in URL Inspection and view the tested page. Compare the rendered HTML with what a visitor sees. If product text, prices or internal links are missing from the rendered version, then rendering moves to the top of the report, whatever else you found.
5. Speed
Read Core Web Vitals by template, not by URL. A slow product template is one finding, not 3,000. Use PSI field data for the verdict and lab tools only to find the cause.
6. Structured Data
Check one URL per template in the Rich Results Test. I look for markup that describes things the page doesn’t show, because that’s the error that costs rich results. Skip HowTo markup completely, and don’t add FAQ markup expecting a rich result, since those stopped showing in Google Search in May 2026.
7. International
Only if the site serves several languages or regions. Hreflang needs return links on every version, and Search Console no longer has an International Targeting report, so a crawler that validates hreflang does this job.
How Do You Score Findings by Impact and Effort?
By now you’ll have a long list. I score each finding on two 1 to 3 scales, then sort. Impact asks how many important pages it touches and whether it blocks indexing. Effort asks who has to fix it and how risky the change is. My symptom-level priority table is in common technical SEO issues; this scoring is for turning your own findings into an order of work.
The rule is simple. Priority equals impact times (4 minus effort), so high impact with low effort floats to the top. Here’s the template. The rows are illustrative examples, not data from a real client.
| Finding | Template affected | Impact (1-3) | Effort (1-3) | Priority score | Owner | Status |
|---|---|---|---|---|---|---|
| Noindex on product template | Product | 3 | 1 | 9 | Developer | Open |
| Product text missing from rendered HTML | Product | 3 | 3 | 3 | Developer | Open |
| Sitemap lists redirected URLs | All | 2 | 1 | 6 | SEO | Open |
| Canonical points to parameter URL | Category | 2 | 2 | 4 | Developer | Open |
| INP poor on mobile | Post | 2 | 2 | 4 | Developer | Open |
| Schema errors on reviews | Product | 1 | 1 | 3 | SEO | Open |
Finding,Template affected,Impact (1-3),Effort (1-3),Priority score,Owner,Status,Evidence link
Example: Noindex on product template,Product,3,1,9,Developer,Open,
Example: Sitemap lists redirected URLs,All,2,1,6,SEO,Open,
,,,,,,,
One adjustment I always make. A finding with impact 3 and effort 3 scores low on paper, but it can’t wait. I flag those as “plan now” so they get scheduled instead of sinking to the bottom forever.
What Should a Technical SEO Audit Report Include?
A technical SEO audit report is a document someone acts on, not a crawler export. Mine has five parts, and the first fits on one screen.
- Summary. The three to five findings that matter most, in plain language, with the business reason for each.
- Scope and data. Which hosts, which dates, which tools, and what you couldn’t access.
- Findings. One block per finding: what’s wrong, the evidence (a screenshot or a URL list), the affected template, the fix and how to verify it.
- Prioritized plan. The scoring table above, sorted, with owners.
- Baseline. The numbers you’ll compare against when you re-check.
Honestly, the evidence column is what earns trust. “Canonical issues found” gets ignored. “Category pages canonicalize to the ?sort= version, here are 214 URLs, here’s the template file” gets fixed by Friday.
When Should You Re-Check the Fixes?
Re-checking is the step everyone skips. It’s also the step that proves the audit was worth paying for. I re-check on three clocks.
Same day: after a fix ships, re-crawl the affected template and run URL Inspection on a few URLs. Within two weeks: in the Page indexing report, use Validate fix on the issue you resolved. Google’s Page indexing report help says validation typically takes up to about two weeks, and sometimes much longer. In my experience, the slow ones are usually templates Google crawls rarely. After 28 days: check field speed data again, since CrUX looks back over the last 28 days and won’t reflect a fix the next morning.
If a fix doesn’t validate, then go back to the evidence, not the theory. Usually one template was missed or a cache is serving the old version.
Edge Cases That Change the Process
- Mid-migration. Audit the redirect map and the staging site before launch, not after. The steps stay the same, but the order flips toward crawlability.
- No Search Console access. You can still crawl and pull PSI data, but say clearly in the report that indexing findings are inferred, not confirmed.
- Tiny sites. On a 20-page brochure site, skip logs and crawl stats. One afternoon with Search Console and a crawler is enough.
- Headless or JavaScript storefronts. Rendering jumps to layer one, because every other layer depends on what Google actually sees.
How to Do a Technical SEO Audit by Site Type
| If your site is… | And your trigger is… | Then focus the audit on |
|---|---|---|
| Small WordPress or Shopify | Routine check | Indexability and speed by template |
| Large store with filters | Slow indexing of new products | Crawlability, duplicates and logs |
| JavaScript app | Pages not ranking at all | Rendering first, then indexability |
| Any site | Sudden drop on a known date | Changes on that date, then indexability |
| Multilingual | Wrong language ranking | International, then canonicals |
When to Hand the Audit to a Specialist
Some findings need a developer who understands SEO: server-side rendering, migrations with thousands of redirects, faceted navigation or log analysis at scale. If you can’t reproduce a problem in URL Inspection, or the fix touches server config, that’s the moment to bring someone in.
That’s the work my team does in our technical SEO service. If you’re new to these terms, start with technical SEO for beginners. Or request a free audit and I’ll tell you which layer I’d start with on your site.
Frequently Asked Questions
How Long Does a Technical SEO Audit Take?
It depends on size and access. A small site with Search Console access can be audited in a day. A large store with logs, several templates and international versions can take a week or more, and most of that time goes into analysis and writing, not crawling.
Can I Do a Technical SEO Audit for Free?
Yes, for most small sites. Search Console, URL Inspection, PageSpeed Insights and the Rich Results Test are free, and Screaming Frog’s free version crawls up to 500 URLs. Larger sites usually need a paid crawler and log access.
What Is the Difference Between a Technical SEO Audit and an SEO Audit?
A technical audit covers crawling, indexing, rendering, speed and markup. A full SEO audit adds content, on-page targeting, links, local signals and AI visibility. The technical part comes first, because a page that isn’t indexed can’t benefit from anything else.
How Often Should You Run a Technical SEO Audit?
I run a full one once a year and after any migration, redesign or platform change. In between, a monthly look at the Page indexing and Core Web Vitals reports catches most problems early.
Last updated: October 2026 by Mizanur Rahman
