A technical SEO audit is a structured look at whether search engines can reach your pages, understand them and choose the right version to show. It is not a list of every possible tweak. It asks one narrower question: is anything in the way the site is built or served getting in the way of crawling, indexing or loading?
Most audits go wrong in the same way: someone exports four thousand rows from a crawler and has no idea what to fix first. This guide fixes the order of the work instead. Check access first, because nothing else matters if Google cannot fetch the page. Then indexing, duplicate-URL signals, rendering, speed and markup. At the end you have one ranked findings sheet that a developer or site owner can act on.
It is written for owners of small and medium sites, freelancers and developers who inherit a site. You do not need paid software, and you will finish with a dated baseline to repeat every quarter.
Short answer: To run a technical SEO audit, check in this order: whether crawlers can reach your pages, which URLs are indexed, how redirects and canonicals behave, whether pages render and load well on mobile, and whether markup is valid. Log each finding with evidence, then rank fixes by effort and impact.
Before you begin
You need three things: access to Google Search Console for the property, the ability to view the live site in a browser (and, ideally, a command line with curl), and a list of the site's main page types. A page type, or template, is a group of pages built the same way: home page, category page, product or article page, search results, contact page. Problems usually belong to a template, so auditing one example of each tells you about thousands of pages.
As a planning estimate, set aside two to four hours for a small site. An audit is read-only, so the risk comes afterwards, when fixes touch redirects or robots rules. Keep a copy of the current robots.txt, redirect configuration and sitemap before anyone changes them. If Search Console is not set up yet, start with Set Up Google Search Console: Complete Website Owner Checklist.
What does a technical SEO audit cover?
Google describes three technical requirements for a page to be eligible for its results: Googlebot is not blocked, the page works and returns a 200 status code, and the page has indexable content. Meeting all three still does not guarantee indexing. An audit tests those requirements across the site, then looks at what decides which URL Google prefers and how well the page works.
| Area | The question it answers | Where you look |
|---|---|---|
| Access | Can crawlers fetch the page? | robots.txt, firewall, login walls, URL Inspection |
| Status codes | Does each URL answer honestly? | curl -I, Page indexing report |
| Indexing | Which pages are in Google and which are not, and why? | Page indexing report |
| Duplicates | Is one version chosen? | Canonical tags, redirects, sitemap |
| Rendering | Is the content and are the links in the rendered page? | URL Inspection, view crawled page |
| Speed | Is the page fast for real visitors? | PageSpeed Insights, Search Console |
| Markup | Is structured data valid and honest? | Rich Results Test |
Step-by-step instructions
Step 1: Set the scope and take a baseline
Write down the canonical address of the site (for example https://www.example.com/), the page types, and the two or three pages that matter most. Record the date, the CMS and any recent migration or redesign. Open Search Console and note the number of indexed and not indexed pages in the Page indexing report, plus any open items in Security Issues. This is your "before" snapshot.
What success looks like: A one-page scope note with a date, a list of page types and a starting count of indexed pages.
Step 2: Check that crawlers can reach the site
Open https://www.example.com/robots.txt in a browser. Look for Disallow: / or rules that block sections you want found. Google says robots.txt controls crawling and is not a way to keep a page out of search, so it is not the right tool for hiding a page. Then check page-level rules: view the source for a robots meta tag and use curl -I to look for X-Robots-Tag. A noindex left over from staging is the classic launch mistake. Finally, run the URL Inspection live test on one page per template. It reports whether the URL is available to Google, which can reveal blocks that a normal browser never sees. See Robots.txt Blocking Google or Bing? Diagnose It Step by Step.
What success looks like: Each template is available to Google in a live test, and no important page carries noindex or a blocking rule.
Step 3: Audit status codes and redirects
Request each template with curl -I and write down the final status code after redirects. Healthy pages return 200. Google's documentation says it follows up to 10 redirect hops in general web crawling, treats 301 and 308 as strong signals that the target should be used, and treats 302, 303 and 307 as weak signals. Chains work, but each hop adds delay and a place to break. Test the four host versions (http and https, with and without www): three should redirect permanently to the fourth in one hop. Then check a missing page: it should return 404 or 410, not a 200 page saying "not found", which Google reports as a soft 404. See Redirect Chains, Loops, and Incorrect HTTP Status Codes for the fixes.
curl -sIL -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective}\n" http://example.com/
What success looks like: One preferred host, one redirect hop at most, honest 404s, and no 5xx responses on any template.
Step 4: Read the Page indexing report
Open Search Console, then Page indexing. The report lists why URLs are not indexed, with reasons such as "Server error (5xx)", "Redirect error", "URL marked 'noindex'", "Soft 404", "Not found (404)", "Crawled - currently not indexed", "Discovered - currently not indexed", "Alternate page with proper canonical tag" and "Duplicate without user-selected canonical". Google notes that many non-indexed URLs are expected, so do not try to empty the list. Ask of each reason: is this a URL I want indexed? A reason that affects wanted pages becomes a finding; one that affects parameter URLs or old redirects is usually fine. Page Indexing Report Explained: Every Status and What to Do covers each status.
What success looks like: Every not-indexed reason is labelled "expected" or "fix", with example URLs.
Step 5: Check canonicals, sitemap and internal links
Canonicalization is how Google picks one URL when several show the same content. Google's guidance ranks the signals: a permanent redirect is a strong signal, a rel="canonical" link is a strong signal, and listing a URL in a sitemap is a weak one. All are hints, not commands, and they should agree. Check three things on each template: the canonical points to a working 200 page, it is an absolute URL, and the same URL appears in the sitemap. Then check the sitemap itself. A sitemap file can hold up to 50 MB uncompressed or 50,000 URLs, Google ignores priority and changefreq, and lastmod is used only when it is consistently accurate. Finally, confirm that every page you want indexed receives at least one internal link, written as an <a> element with an href. See Fix Duplicate URLs and Incorrect Canonical Tags and Orphan Pages: How to Find Pages With No Internal Links and Fix Them.
What success looks like: Canonical, redirect and sitemap signals name the same URL for each page, and no wanted page is an orphan.
Step 6: Test rendering and the mobile version
Google indexes the mobile version of a page, so the mobile page needs the same primary content, headings, titles, descriptions and structured data as desktop. Use the URL Inspection tool, run a live test and open the rendered page and the crawled HTML. Search the HTML for your main heading, a paragraph of body text and a navigation link. Content added only after a user action, or links built with onclick instead of <a href>, may not be seen. Google also warns that removing noindex with JavaScript may not work, and advises against URL fragments for loading different content. Read JavaScript SEO: Server Rendering, Client Rendering and Crawlers when the rendered HTML looks thin, and compare the mobile and desktop versions.
What success looks like: The rendered HTML for each template contains the main content, the title and crawlable links, on mobile as well as desktop.
Step 7: Measure speed with field data first
Run each template through PageSpeed Insights and read the real-user block before the Lighthouse block. Google's Core Web Vitals targets, measured at the 75th percentile, are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less. Use the lab result to find causes and the field result to decide whether there is a problem. Google recommends good Core Web Vitals but does not promise a ranking change from them. See PageSpeed Insights Explained: Field Data, Lab Data and Why They Differ.
What success looks like: You have field values for each template where Google has enough data, and a note of the slowest element for those that fail.
Step 8: Check markup, then log and rank every finding
Test pages that carry structured data in the Rich Results Test. Google's preferred format is JSON-LD, the markup must describe content visible on the page, and valid markup does not guarantee a rich result. Check that each template has a unique, clear title.
Now bring everything into one sheet. One row per finding, one template or URL group per row:
| ID | Area | Finding | Evidence | Pages affected | Effort | Impact | Owner | Status |
|---|---|---|---|---|---|---|---|---|
| T-03 | Redirects | http://www goes to https:// in two hops |
curl output above |
All | Low | Medium | Developer | Open |
| T-07 | Indexing | 120 product URLs "Discovered - currently not indexed" | Page indexing export | 120 | Medium | Unknown | Content | Investigate |
Rank blockers first: anything that stops crawling or indexing of wanted pages (a stray noindex, a blocked directory, a 5xx on a template). Next come low-effort fixes for inconsistency, such as redirect hops and canonical mismatches, then template work, then items whose benefit you cannot show. Write "Unknown" in the impact column rather than guessing a figure.
What success looks like: A ranked sheet where every row has evidence, an owner and a status.
What do I do after the audit?
Fix one group at a time and recheck it. Google's Search Console guidance says to fix all instances of an issue before clicking Validate fix, and validation can take about two weeks. Google also says changes can take from a few hours to several months to show up, so judge results after weeks. Repeat the audit after any migration or redesign; Website Migration SEO Checklist: Move a Site Without Losing Visibility covers that case. Crawvix automates part of the routine: it runs about 115 checks in ten areas, but a person still has to judge which findings matter.
Final verification checklist
- The scope note lists the canonical host, page types and starting indexed count.
- robots.txt, meta robots and
X-Robots-Taghave been checked for every template, and none blocks a wanted page. - Each template returns 200, the four host versions end at one address, and missing pages return a real 404 or 410.
- Every reason in the Page indexing report is labelled expected or fix.
- Canonical, redirect and sitemap agree for sampled pages.
- The rendered HTML of each template contains content and crawlable links.
- Field data and Lighthouse results are recorded for each template.
- Structured data passes the Rich Results Test where used.
- The findings sheet is ranked and each row has evidence, an owner and a status.
Common mistakes to avoid
- Starting with speed scores. A fast page that returns noindex helps nobody. Check access and indexing first.
- Treating every not-indexed URL as an error. Many are expected. Decide per reason.
- Auditing only the home page. Problems sit in templates. Test one page of each type.
- Recording findings without evidence. Save the command output, screenshot or exported URL list so the fix can be confirmed later.
- Promising an outcome. An audit finds problems. It cannot say what rankings or traffic will do afterwards.
- Never repeating it. Sites drift. Repeat after releases and at least quarterly.
Frequently asked questions
How long does a technical SEO audit take?
For a small site with a handful of templates, two to four hours is realistic once you have Search Console access. Large sites take longer.
What tools do I need for a technical SEO audit?
Free tools cover the essentials: Google Search Console, the URL Inspection tool, the Rich Results Test, PageSpeed Insights or Lighthouse in Chrome DevTools, a browser and curl. A site crawler helps on larger sites because it checks many URLs at once.
How often should I run a technical SEO audit?
Run a light version quarterly and a full one after any migration, redesign, CMS change or large content change. Between audits, watch Search Console for new errors. Website Maintenance Checklist shows a monthly routine.
Will fixing technical issues improve my rankings?
Not by itself and not on a schedule. Technical fixes remove obstacles so that pages can be crawled, indexed and loaded properly. Whether a page ranks depends on many other things, including its content and competing pages.
What should I fix first?
Fix anything that stops wanted pages from being crawled or indexed, such as stray noindex, blocked directories, server errors and bad redirects. Then fix inconsistencies between canonical, redirect and sitemap signals. Cosmetic items come last.
Related guides
- Technical SEO Checklist: Checks to Run Before and After Launch
- Website Launch SEO Checklist: What to Verify Before You Go Live
- Page Indexing Report Explained: Every Status and What to Do
- How do I check if a page is indexed by Google?
- Website Maintenance Checklist: Monthly, Quarterly and Yearly Tasks
Official references
- https://developers.google.com/search/docs/essentials/technical
- https://developers.google.com/search/docs/crawling-indexing/http-network-errors
- https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
- https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
- https://support.google.com/webmasters/answer/7440203
- https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
- https://developers.google.com/search/docs/fundamentals/seo-starter-guide
Next step: Try the free website sample to see how your own site does on a few of these checks. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.