Technical SEO Audit: What It Covers + Free Checklist

Most SEO advice starts with keywords and content. That is the visible part. Underneath it sits a plainer question: can Google actually reach your pages, read them, and store them? If the answer is "not reliably", better content will not fix it.

This guide explains what a proper audit of that layer looks at, why each part matters, and how to check it yourself. The checklist further down is free to copy. Where Google has published how something works, we link to its own documentation instead of repeating hearsay.

What technical SEO is checking for

Google describes Search in three stages: crawling, indexing, and serving results (How Google Search works). Technical SEO is about the first two. A page that is never crawled cannot be indexed, and a page that is not indexed cannot rank, however good it is.

So an audit asks a short chain of questions about every important URL:

1. Can Googlebot reach it? (crawl)
2. Is it allowed and chosen to be stored? (index)
3. Does the content still appear once the page is rendered? (render)
4. Is the experience fast and stable for real visitors? (speed and Core Web Vitals)
5. Does the mobile version carry the same content? (mobile)
6. Can Google understand what the page is about? (structured data)
7. Can it find the page through links and the sitemap? (internal links, sitemap, robots)

If you are new to the topic, start with our beginner guide, what is technical SEO. The rest of this post assumes you know the basic terms and want to check a real site.

Crawl: can Google reach your pages?

Crawl problems are the most damaging because they hide everything else. The usual causes are simple.

• Status codes. Important pages should return 200. Removed pages should return 404 or 410, not a 200 "soft 404" page that says "not found". Google documents how it treats each status code in HTTP status codes and network errors.
• Redirects. Use permanent (301 or 308) redirects for moved URLs and avoid chains of several hops. See Google's page on redirects and Google Search.
• robots.txt. One wrong Disallow line can block a whole folder, or the CSS and JavaScript files Google needs to render the page. Google's introduction to robots.txt also makes a point many site owners miss: robots.txt controls crawling, not indexing. A blocked URL can still appear in results if other pages link to it.
• Server health. Frequent 5xx errors or timeouts make Google slow down its crawling. Search Console's Crawl Stats report shows these.

Index: is the right version stored?

Being crawled is not the same as being indexed. The index checks look for pages that are excluded by mistake, and for duplicates that split your signals.

• noindex tags. A noindex meta tag or X-Robots-Tag header removes a page from results. Staging settings left on after launch are a common cause. Google explains both methods in block search indexing with noindex. Note that Google must be able to crawl the page to see the tag, so do not combine noindex with a robots.txt block.
• Canonical URLs. The same content often lives at several addresses: with and without www, with tracking parameters, or with filter options on a shop. A rel="canonical" tag tells Google which one you prefer. Google treats it as a strong hint rather than a command, as its guide to consolidating duplicate URLs explains.
• Page indexing report. In Search Console, this report lists every URL Google knows about and why each excluded one was left out. It is the single most useful screen in the whole audit.

Render: does the content survive JavaScript?

Many modern sites build their content in the browser with JavaScript. Google can render JavaScript, but it happens as a separate step, and content that only loads after a click or a scroll may never be seen. Google's JavaScript SEO basics covers the details.

To check it, open the URL Inspection tool in Search Console, run a live test, and look at the rendered HTML. Are the main text, the links, and the title tag all there? If key content is missing, the fix is usually server-side rendering or static generation for those pages.

Speed and Core Web Vitals

Google uses Core Web Vitals as part of its page experience signals (Understanding Core Web Vitals and Google search results). There are three metrics, and web.dev publishes the "good" thresholds (Web Vitals):

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024 (web.dev announcement). If a report or plugin still grades your site on FID, it is out of date.

Google measures these at the 75th percentile of real visits, so check field data (the Core Web Vitals report in Search Console, or the top section of PageSpeed Insights) before lab scores. The usual culprits are oversized images, render-blocking scripts, slow hosting, third-party widgets, and images or ads without reserved space. If your audit flags these, our website speed optimization service is built for exactly that work.

Mobile: is the phone version complete?

Google uses the mobile version of a page for indexing and ranking (mobile-first indexing best practices). That makes the mobile page the real page as far as Google is concerned. If text, images, structured data, or links are hidden or removed on mobile, Google may never see them.

The audit compares the two versions side by side. It also checks the basics: a correct viewport tag, text readable without zooming, and tap targets that are not crammed together. In Bangladesh, where most people browse on phones, this is rarely a minor issue.

Structured data: can Google understand the page?

Structured data is code (usually JSON-LD) that labels what a page is: an organisation, a local business, a product, an article, an FAQ. Google uses it to understand content and, for supported types, to show rich results. Its introduction to structured data lists the formats and rules.

The audit checks three things. Is the markup valid, with no errors in the Rich Results Test? Does it describe content that is actually visible on the page? And is the business information (name, address, phone) the same everywhere it appears? Markup that describes things the visitor cannot see goes against Google's guidelines.

Internal links, sitemap, and robots

Google finds most pages by following links. Its guide to crawlable links says links should be real <a> elements with an href, not buttons that only work with JavaScript.

An audit maps the internal links and looks for:

• Orphan pages that no other page links to.
• Deep pages that take many clicks to reach from the homepage.
• Broken internal links and links that point to redirected URLs.
• Vague anchor text such as "click here", which tells Google nothing about the target.

The XML sitemap should list only the canonical, indexable URLs that return 200, and it should be submitted in Search Console. Google's sitemaps overview explains the format and limits. A sitemap full of redirects, noindexed pages, or 404s sends mixed signals.

The technical SEO audit checklist

Copy this into a spreadsheet and work through it one area at a time. Mark each line pass, fail, or not applicable, and note the URLs that fail.

A short version of the same list, if you only have an hour:

• Open the Page indexing report and read every exclusion reason
• Run URL Inspection's live test on your homepage and one key service page
• Check field Core Web Vitals in Search Console or PageSpeed Insights
• Load robots.txt and read every Disallow line
• Open your XML sitemap and spot-check ten URLs
• Test your structured data in the Rich Results Test

How to prioritise what you find

An audit can easily return a hundred issues. Not all of them matter equally. A sensible order is:

1. Anything that stops crawling or indexing of important pages: blocks, noindex, broken canonicals, server errors.
2. Problems that affect whole templates, such as a missing canonical on every product page, because one fix repairs hundreds of URLs.
3. Core Web Vitals failures on your highest-traffic pages, using field data.
4. Structured data errors and internal linking gaps.
5. Cosmetic warnings that a tool flags but that do not change how Google treats the page.

Be wary of any report that only gives a score. A number out of 100 does not tell you what to fix first. A useful audit names the URL, the problem, the reason it matters, and the fix.

DIY audit or professional help?

For a small site with a few dozen pages, the checklist above and a free Search Console account will catch most problems. You can do it in an afternoon.

Larger sites, online shops with filters, and sites built on JavaScript frameworks are harder. Duplicate URLs multiply, rendering issues hide, and fixes often need a developer. That is where a paid technical SEO service earns its cost: a full crawl, the written issue list, and the fixes themselves. Typical costs are listed on the SEO and web design pricing page.

Get a free audit of your site

Want a second pair of eyes before you spend anything? Request our free SEO audit. You get a plain-language report on your rankings, technical health, and speed, plus the quick wins, and you decide what, if anything, to do next. Either way, a technical audit is worth repeating after every redesign, platform move, or major change to your URLs.