Technical SEO audit: a practical checklist

An SEO audit is useful when its findings lead to decisions that can be tested. I start by identifying which pages should appear in search, then check whether search engines can discover and fetch them, whether URL signals are consistent and whether the content serves the intended query.

The steps cover indexability, redirects, internal links, structured data and page performance. For each technical issue, the report should explain how to reproduce it and how to check that it has been fixed. Link-profile data needs separate interpretation alongside those tests.

Technical SEO audit: what to check and in what order

A technical SEO audit is a check of whether crawlers can discover and fetch your important URLs, then understand them. You run it in a fixed order: status codes and robots.txt first, then sitemaps, canonicals and redirects, then internal links, and speed and structured data last.

It's one part of a full SEO audit: a review of a site that ends in a list of the things stopping it from earning search traffic, in the order you should fix them. A list of everything that could be improved is endless and helps no one. A full audit covers three areas, and you can automate each one to a different degree.

The fourth element is the report. Findings need to be clear enough that someone other than the author can review the evidence and carry out the recommended work. Every finding in it needs evidence, the affected URL, and a criterion that tells you the problem is gone. I cover this in the guide to a client-ready audit report.

An audit won't promise you a position or a date. It also won't decide for you who the site is for and what it should be about.

Full SEO audit step by step

An SEO audit has eight steps, and their order matters, because if the crawler doesn't fetch a page, improving its content is wasted work.

1. Set the scope and a baseline. Write down what you measure and where the data comes from (Search Console, a crawler, field data), because without a starting point you can't prove later that anything improved.
2. Check that crawlers can reach the site at all. HTTP status codes, robots.txt, noindex, crawl budget. This is where most problems that looked like "weak content" end.
3. Verify the canonical signals. Canonicals and redirects must say the same thing as the sitemap and internal links. Conflicting signals are the most common reason Google indexes a different URL from the one you wanted.
4. Measure performance with field data, on top of lab data. The lab tells you what can be improved, and data from real users tells you whether it's worth doing.
5. Review content against intent. A page that answers a different question from the one typed into the search box won't win with any heading.
6. Look at the link profile. What matters is who links to you and in what context, because a domain counter can be inflated with spam in a week.
7. Rank the findings by impact and implementation cost.
8. Set a retest date, because an audit without a repeat is an opinion. Only a second measurement with the same method shows whether the fix worked.

Steps 2–4 can largely be automated, and they're where the SEO module in CometWeb Insight, our website audit app, starts. Steps 5–7 need someone who knows your business. I ran step 6 on the numbers from the intro. A PBN is a network of sites set up to sell links, and this one showed my domain as a sample in its offers.

There was no manual action, so I didn't file a disavow. The lesson? The link count told me nothing, but the anchor distribution did.

Technical SEO: what it is and what it covers

Technical SEO is everything that makes it easier for Google's bots (and other search engines) to fetch your site, understand its structure, and index its content. Google's SEO Starter Guide describes the same path, from discovering a page to understanding it, and technical SEO itself covers five areas:

• indexing and crawlability, meaning whether Google can "see" your pages at all,
• loading speed (Core Web Vitals),
• URL structure and internal linking,
• security (HTTPS),
• structured data (Schema.org).

Technical SEO audit checklist

A useful technical SEO audit combines a full-site crawl with manual checks of representative URLs. Don't stop at the homepage, because issues often live only in one template (article, module, product) or in a legacy URL.

Your XML sitemap lists only URLs you want indexed

A sitemap is an XML file that tells Google: "Here are the important pages, please index them." Without one, bots find your pages only by following links, and they may miss some.

• Generate it with Yoast SEO or Rank Math. Screaming Frog can do it too, and most CMS platforms have it built in.
• Submit its URL (e.g., domain.com/sitemap.xml) in Google Search Console > Sitemaps.
• Keep only pages you want indexed in it, and use the table above to see what to take out.

It also helps with orphan pages, which no internal link points to, so Google may not find them any other way. My internal link audit shows how to catch them and link them properly.

Robots.txt blocks only low-value pages

Robots.txt tells bots which parts of your site they can crawl and which to avoid. According to Google's robots.txt documentation, the file is mainly for managing crawler traffic, so to keep a page out of the index, use noindex.

• Block the shopping cart, internal search results (/search/), and admin panels, because these pages waste your crawl budget, which is how many URLs Googlebot can and wants to fetch.
• Keep the file in the root directory: domain.com/robots.txt.
• Check it in the robots.txt report in Google Search Console. It shows which robots.txt files Google found and any errors it hit, and one bad line can block crawling of your entire site.

Page speed meets the Core Web Vitals thresholds

According to Google's page experience documentation, loading speed is one of the signals Google's ranking systems use, not a standalone factor that outweighs relevance. Google measures it with Core Web Vitals, three user-experience metrics. web.dev sets the "good" thresholds, and I lay them out in a table in the guide to speeding up a website.

On the cometweb.io homepage, the brake on LCP turned out to be JavaScript loaded before first render. The before-and-after measurement is in my guide to lab data versus CrUX, along with why a lab run rarely agrees with the field data Google uses and what that changes about your fix order.

• Compress images with TinyPNG or Squoosh, and on WordPress with a plugin (ShortPixel, Imagify). Use WebP and AVIF.
• Lazy-load images and media (loading="lazy"), but skip it on the image that is the LCP element.
• Set up a CDN. Cloudflare (the free plan is enough to start) serves resources from the server closest to the user.
• Minify CSS, JS and HTML, which means cutting unneeded characters from the code, such as spaces and comments. Obfuscation is a different job: it makes JavaScript harder to read, not faster. If that is what you need, the JavaScript obfuscator online runs in your browser.

Pay special attention to render-blocking resources, excessive DOM, and enormous network payloads. Our website speed guide shows you how to separate the root cause from the metric, and in Insight the performance module lays out the fix order.

Your site works on a phone (mobile-first indexing)

Google uses mobile-first indexing, so the mobile version of your site is the baseline for indexing and ranking. If your site looks great on a computer but you can't read it on a phone, it's a poor site in Google's eyes.

• Test responsiveness at a few resolutions. Chrome DevTools (F12 > device toolbar) does it without leaving your browser.
• Give buttons and links at least 48x48 px and enough spacing so nobody taps them by accident.
• Set body text on mobile to at least 16 px, because anything smaller forces zooming.

URLs are short, descriptive, and close to the homepage

A good URL tells your visitors where they are and helps Google understand your content hierarchy. Compare www.domain.com/blog/technical-seo with www.domain.com/?p=12345. The first says what the page is about and carries a keyword, while the second is unreadable.

• Separate words with hyphens, which Google recommends over underscores, because they make the individual words easier to read.
• Skip special characters and capital letters, since a simple URL is easier to index and share.
• Keep the architecture flat, so every important page should be within 2–3 clicks of the homepage, because the deeper you bury a page, the less "SEO juice" reaches it. A crawler shows click depth, e.g., the Crawl Depth column in Screaming Frog.

Your whole site runs on HTTPS

Chrome has marked sites without SSL as "not secure" for years, and HTTPS is part of the page experience Google's ranking systems consider, and it's free to set up.

• Get a free Let's Encrypt certificate, which most hosting providers install in one click.
• Switch internal links and resources (images, scripts) to HTTPS.
• 301-redirect every HTTP address to HTTPS, no exceptions, because otherwise Google sees two versions of the same page.

Check it with curl -I http://domain.com: it should return a 301 with a Location header pointing to the https address. The HTTPS report in Search Console shows the state of the whole site.

Every piece of content has one canonical URL

Duplicate content is one of the most common technical issues you'll find. It's usually accidental, caused by URL variants (www or non-www, trailing slash or none), filtering parameters, or language versions. Google's canonicalization documentation explains how you tell Google which URL you prefer.

• Mark the original with a rel=canonical tag, which tells Google which version of a page to index.
• Find duplicates with Screaming Frog or Siteliner.
• Pick one version of the URL and 301-redirect the rest.

After changing URLs, compare "User-declared canonical" with "Google-selected canonical" in Search Console, because if they differ, Google picked the version for you. Our guide to canonical URLs, sitemaps, and robots.txt shows you how to spot a conflict between those signals and walks through a full URL migration.

In online stores, duplicates rarely come from copied text, because filters create URLs showing the same product list, and product variants add more. The e-commerce SEO audit explains how to count those URLs and which version to keep in the index.

Structured data describes what's visible on the page (rich snippets)

Structured data "explains" to Google what specific elements on your page are. Some types make a page eligible for rich results: star ratings, product prices, recipes, breadcrumbs. JSON-LD should describe what the reader sees. Google's structured data guidelines say to mark up only visible content, so a rating or a price that exists only in the markup breaks the rules.

FAQ and HowTo rich results were retired and no longer appear in Google's search gallery as of September 2026. Both types still describe content, but Google no longer shows a rich result for them.

• Google, Bing and Yahoo all support the Schema.org standard. The most commonly used types are Article, Product and LocalBusiness.
• On WordPress, plugins (Yoast SEO, Rank Math) let you add structured data without writing code, and on a custom-built site put JSON-LD in the <head> section.

A schema validator checks syntax and structure, a schema checker helps find common issues, and Google's Rich Results Test checks eligibility for selected result features. None of these tools guarantees a rich result or higher rankings.

The structured data glossary and my article on schema validators and schema checkers cover the whole workflow. Insight's SEO module detects JSON-LD on a public page and flags issues that can be verified automatically, but Google's validator gets the final word.

Technical SEO audit tools

Four tools cover a technical audit, and three of them are free or have a free version.

I'd start with Search Console and a crawler, because the first shows you what Google sees, and the second shows what a bot following your links sees. In Insight, you can combine the SEO audit with the Crawl module to connect page-level signals with URL flows, including redirects and sitemaps. The audit methodology defines the scope of both modules.

Insight complements Search Console and a full crawler. It earns its keep at step 8, because it puts two crawls side by side and shows new errors, fixed URLs, and changed statuses.

Final thoughts: where to start with technical SEO

Technical fixes require verification after release and periodic checks as templates, content and dependencies change. Fix the critical errors first, then the rest in this order:

To sharpen your content next, read my guide to on-page SEO, and you can automate steps 2–4 and the retest in Insight. Start a free audit in CometWeb Insight.

Do you run your audit in a different order and get good results? Tell me at maciej@cometweb.io.

Frequently asked questions

Sources

1. Google Search Central: SEO Starter Guide, fundamentals of discovery, indexing, and content description.
2. Google Search Central: robots.txt, scope and limits of robots rules.
3. Google Search Central: canonicalization, selecting a preferred URL.
4. web.dev: Core Web Vitals, user-experience metrics and thresholds.
5. Google Search Central: page experience, how Core Web Vitals and HTTPS fit into page experience.
6. Search Console Help: robots.txt report, which robots.txt files Google found and the errors it hit.
7. Google Search Central: URL structure, the recommendation to use hyphens instead of underscores.
8. Google Search Central: structured data guidelines, marking up only visible content.

The article was updated on 24 September 2026 with the scope of a full SEO audit and a step-by-step process alongside the technical section, plus an in-page HTML signal checker.