To perform a technical SEO audit, you crawl your site the way Google does, then work through a fixed checklist: crawlability, indexing, site speed and Core Web Vitals, mobile, structured data, canonicals, and sitemaps. That is the whole job. It is less mysterious than most agencies make it sound, and honestly, a lot of the “advanced” version is just checking whether Google can read the page without tripping over something you left on the floor.
Here is the part nobody says out loud. Most technical problems are boring. A blocked page. A slow image. A canonical tag pointing at the wrong URL. None of it is glamorous, and all of it can quietly keep a good page from ranking. So let me walk through the audit in the order I actually run it, from the crawl to the report.
Start by crawling your site the way Google does
Every technical SEO audit starts with a crawl. A crawler like Screaming Frog, Sitebulb, or the Semrush Site Audit walks your site the way a search engine does: it follows every internal link, records the status code of each URL, and flags pages that redirect, error, or vanish. You point it at your homepage, let it run, and it hands you a map of what actually exists versus what you think exists.
That gap is usually where the surprises live. I have opened a crawl and found redirect chains four hops deep, pages returning a soft 404 while pretending to be fine, and internal links still pointing at the old HTTP version of the site. Google is patient, but it is not a mind reader. Every broken link and pointless redirect is a small tax on the crawl, and you want to find those before Google does.
Sort the crawl by status code first. Fix the 404s that have inbound links, clean up redirect chains so they resolve in one hop, and note anything returning a 5xx server error. This is the cheapest, highest-value hour of the whole audit.
Check what Google can actually crawl and index
A page that cannot be crawled cannot be indexed, and a page that is not indexed cannot rank. So the next question is simple: what is Google allowed to see, and what has it actually kept?
Start with robots.txt. Make sure you are not accidentally blocking a section you want ranked (a shocking number of sites block /blog/ or an entire staging path that went live by mistake). Then open the Pages report in Google Search Console. It tells you which URLs are indexed, which are excluded, and why. Google’s own documentation on how Search works is the clearest explanation of crawling and indexing if you want the source, not the summary.
Cross-check that against a site:yourdomain.com search. If Google shows far fewer pages than you published, something is blocking them. If it shows far more, you probably have duplicate or junk URLs getting indexed that should not be. Both are worth chasing down. Indexing problems are the ones that feel invisible, because the page looks perfect to you and simply does not exist to Google.
Canonicals decide which version of a page counts
Duplicate content is rarely someone copying your work. It is usually your own site serving the same page at several URLs: with and without a trailing slash, with tracking parameters, with www and without. Google has to pick one version to rank, and if you do not tell it which, it guesses. (Google, famously, does not accept vibes as structured data.)
The canonical tag is how you make that call yourself. During the audit, check that each page points its rel="canonical" at the single URL you actually want ranked, and that the canonical is not accidentally pointing every page at the homepage, which I have seen more than once. Self-referencing canonicals on your main pages are fine and expected. The goal is one clear preferred URL per piece of content, so Google spends its energy ranking the page instead of untangling your duplicates.
Core Web Vitals are where most sites quietly bleed
Speed is a confirmed ranking signal, and Google measures the user-facing part of it through Core Web Vitals: loading (Largest Contentful Paint), interactivity (Interaction to Next Paint), and visual stability (Cumulative Layout Shift). Run your key templates through PageSpeed Insights, which reports both lab data and the real-world field data Google actually uses.
Most sites lose here in the same predictable ways. A giant unoptimized hero image. A pile of third-party scripts loading before the content. A layout that jumps around as ads and fonts pop in. Pretty is not the same as fast, and Google keeps score. Fix the heavy images first, defer the scripts that do not need to run immediately, and reserve space for anything that loads late so the page stops shifting under people’s thumbs. A perfect score is not the goal. A page that loads fast enough that people stick around is.
Mobile is the version Google actually ranks
Google uses mobile-first indexing, which means the mobile version of your site is the version it evaluates. Not the desktop one you designed on a 27-inch monitor. If content, links, or structured data exist on desktop but get stripped out on mobile, Google effectively does not see them.
In the audit, check that the mobile page serves the same important content and links as desktop, that tap targets are not crammed together, and that text is readable without pinching. Use the URL Inspection tool in Search Console to see how Googlebot actually renders the page, including whether your CSS and JavaScript loaded. What you see on your phone and what Googlebot sees are not always the same thing, and the render is where you catch the difference.
Schema tells Google and AI search what the page is
Structured data is how you label a page in a language machines read. It does not change how the page looks to a person. It tells Google that this block is a FAQ, this is an article, this is a local business, this is the author. Schema is not decoration. It is how you tell Google what the page actually is, and Google’s structured data documentation lists which types are eligible for rich results.
This part matters more every year because of AI search. Answer engines like ChatGPT and Google’s AI Overviews lean on clean structure and clear entities to decide what a page is about and whether to cite it. A page that is easy for a machine to parse is easy for an answer engine to quote. So in the audit, validate your schema with Google’s Rich Results Test, confirm the markup matches what is visible on the page, and fix any type that throws errors. A marketer treating AI search as a fad is like hearing thunder and deciding weather is a trend. It is already part of how people find answers.
Confirm your sitemap and internal links point the right way
Your XML sitemap is the list of URLs you are asking Google to crawl. Open it and make sure it contains your real, indexable, canonical pages, and nothing else. No redirects, no 404s, no noindex pages, no parameter junk. Then confirm it is submitted in Search Console. A sitemap full of dead URLs is not a map. It is a set of directions to houses that were demolished.
Internal links do the quieter work. They spread authority around your site and help Google understand which pages matter and how they relate. During the audit, look for orphan pages with no internal links pointing to them, and make sure your important pages are linked from somewhere people and crawlers will actually reach. This is also where a general website audit and a technical one overlap, so it is worth doing both with the same crawl data.
Serve the whole site over HTTPS, all of it
HTTPS is a lightweight ranking signal and, more importantly, a trust one. Browsers now flag plain HTTP pages as “not secure,” which is not the first impression you want. In the audit, confirm the entire site loads over HTTPS, that HTTP versions redirect to HTTPS in a single hop, and that there is no mixed content: a secure page loading an image, script, or stylesheet over insecure HTTP. Mixed content is easy to miss because the page looks fine, and the browser console is where it quietly complains. It is a small fix that removes a small, needless doubt.
The technical SEO audit checklist
Here is the whole audit in one place. Run top to bottom, fix what is red, and note what you cannot fix yourself so it lands with the right person.
| Area | What to check | Where to look |
|---|---|---|
| Crawlability | Status codes, redirect chains, broken links | Screaming Frog, Sitebulb, Semrush |
| Indexing | Indexed vs excluded pages, blocked paths | Search Console Pages report, site: search |
| Robots + directives | robots.txt rules, stray noindex tags | robots.txt, page source |
| Canonicals | One preferred URL per page, no duplicates | Crawler, page <head> |
| Core Web Vitals | LCP, INP, CLS, image and script weight | PageSpeed Insights |
| Mobile | Same content as desktop, readable, renders | URL Inspection tool |
| Structured data | Valid schema, matches visible content | Rich Results Test |
| Sitemaps | Only live canonical URLs, submitted | XML sitemap, Search Console |
| HTTPS | Whole site on HTTPS, no mixed content | Crawler, browser console |
| Internal links | No orphan pages, key pages linked | Crawler |
A perfect audit is not the same as a good page
Here is my one strong opinion, and I will stand on it. Technical SEO matters, but it is not the whole game. A technically flawless page that says nothing still says nothing. It just says nothing efficiently.
Still, the audit earns its keep in a way people forget. I like to run this exact checklist on marketing companies before I trust one, and it is a little too revealing how often their own site comes back slow, with a sad Lighthouse score and pages a crawler has to fight to reach. That is the tell. A company’s own website is the easiest client it will ever have. No approval chain, no waiting on photos, no owner asking if the logo can be bigger. If a company cannot pass the audit on the one site it fully controls, it is fair to wonder how carefully it will run yours. Call it checking the chef’s kitchen before ordering the steak.
So run the audit, fix the technical debt, and then remember why. The point is to give a genuinely useful page a fair shot at ranking, not to chase a green score for its own sake. Google cannot rank a page it cannot understand, but it also will not rank a page nobody needs. If you want the ranking half of the story after the technical half is sorted, that is what organic SEO is for. And if you are still fuzzy on the concepts themselves, the technical SEO basics guide covers the what and why before this how.
Frequently asked questions
How do you perform a technical SEO audit from start to finish?
Crawl the site with a tool like Screaming Frog or Semrush, then work through a fixed order: crawlability and status codes, indexing, canonicals, Core Web Vitals, mobile, structured data, and sitemaps. Fix the blocking issues first, note what needs a developer, and finish with a short report of what you changed and what to monitor.
What is the difference between a technical SEO audit and a general SEO audit?
A technical SEO audit focuses on whether search engines can crawl, render, and index your site: speed, structure, schema, canonicals, and status codes. A general website audit is broader and also looks at content, keywords, and conversion. The technical audit is the foundation the rest sits on.
What tools do I need for a technical SEO audit?
A crawler (Screaming Frog, Sitebulb, or Semrush Site Audit), Google Search Console, and PageSpeed Insights cover most of it. The Rich Results Test validates structured data, and the URL Inspection tool shows how Googlebot renders a page. You can run a solid audit with the free tiers of most of these.
How often should I run a technical SEO audit?
A full audit once or twice a year is reasonable for most sites, with a lighter check after any big change: a redesign, a migration, or a platform switch. Keep an eye on the Search Console Pages report between audits, since it flags new indexing problems as they appear rather than months later.
Do I need to be a developer to do a technical SEO audit?
No. You can find and understand most issues with the tools above and a bit of patience. Some fixes, like server response times or template changes, need developer help. Finding the problem and fixing the problem are two different jobs, and the audit is mostly the first one.
Does a technical SEO audit guarantee better rankings?
No, and anyone promising that is selling fairy dust with a login. An audit removes the technical obstacles that hold a page back, which gives good content a better chance to rank. Rankings still depend on the content, the search intent, and the competition. Give any SEO work at least three months before judging it, and honestly, more time is better.
How long does a technical SEO audit take?
For a small site, a focused audit takes a few hours. For a large site with thousands of URLs, the crawl alone can run a while, and interpreting it takes longer. The fixing usually takes more time than the finding, especially when developer work is involved.
Run the audit, then fix what matters
A technical SEO audit is not a magic trick. It is a checklist run in order: crawl, index, canonicals, speed, mobile, schema, sitemaps. Do it honestly and you will find the boring problems quietly holding back pages that deserve to rank.
Want an honest read on where your site stands right now? Run a free audit for a quick technical health check, and start with whatever comes back red. Fix the foundation first. Then the good content on top has a fighting chance.