Technical SEO Audit Checklist: What to Check and What to Fix First

A crawler export can flag nearly every URL on a site, yet only a few of those flags decide whether pages get indexed. This technical SEO audit checklist covers twelve areas, from crawling and indexing through to server logs on large sites. Each item gives a reason and names the report or response where the problem shows up.

It is written for a marketing lead or developer running the audit in-house, or deciding whether to hire help.

What a technical SEO site audit covers

Google Search works in three stages, and Google does not guarantee that any page gets through all of them. Crawling fetches the page, and indexing reads it and chooses a canonical version when duplicates exist. Serving then returns indexed pages in results for a query. A technical SEO site audit finds the places where your own site stops a page before it reaches that last stage.

Content quality and backlinks belong in a separate review, even though many SEO audit checklists mix them in. We keep them apart because developers fix most technical findings.

You need these tools:

• Google Search Console, for the Page indexing, HTTPS, Core Web Vitals and Crawl Stats reports and for URL Inspection.
• A site crawler that runs on raw HTML and with JavaScript rendering. Its export lists each linked URL with its status code, title, canonical and depth.
• PageSpeed Insights and the Rich Results Test.
• A browser's view-source and developer tools, to read what the server sends.
• Server access logs, on large sites only.

How to do a technical SEO audit, step by step

These five steps turn the checklist's findings into fixed tickets. Our guide to technical SEO for SaaS sites adds checks for separate docs and app hosts.

• Scope the site by listing every host, such as www, docs and help. Then list the page templates on each host and mark the ones that bring in leads or revenue, because those get checked first.
• Collect the data before you judge it, and write down the date of each export.
• Work through the checklist by area, sampling a few URLs from each template.
• Confirm each problem at the source. A crawler warning is only a lead, and the proof is the status code, the HTML or the URL Inspection result.
• Rank the findings, then write each one up as a task with an owner and a test.

We audit each site by template. A missing canonical on the product template is one finding with one fix, even when the crawler lists it for every product page.

The technical SEO audit checklist, by area

The twelve groups follow roughly the order we check them in. Groups 1 to 4 apply to every site, while group 12 is only worth the time on a large one.

1. Crawling and indexing

Start with the Page indexing report in Search Console. It lists the URLs Google did not index, with a reason for each. Google says a site under 500 pages probably does not need it, and suggests site: searches as a first check instead.

Several of its reasons describe normal behavior:

• "Crawled - currently not indexed" is often harmless, since Google does not index every page it crawls. It matters only for URLs you want people to find.
• "Discovered - currently not indexed" means Google put off crawling the URL, usually because it expected the visit to overload the site. A long list on an important template can point to a slow server.
• "Duplicate, Google chose different canonical than user" means Google disagrees with your canonical tag. Compare the user-declared and Google-selected canonical in URL Inspection.
• The Source column shows who can act. Google says you can generally fix only issues whose source is "Website".

Then check the key pages one at a time:

• Each key template returns a 200 status code.
• No key page carries noindex in the robots meta tag or in an X-Robots-Tag HTTP header. The header never appears in the page source, so read the response headers too.
• URL Inspection shows the page as indexed, with the canonical you expect. Its default view is Google's last indexed copy, so use Live Test to check the page as it is today.
• No important URL is listed as "Indexed, though blocked by robots.txt". That status means Google indexed the URL from links without reading the page.

2. robots.txt and XML sitemaps

robots.txt tells crawlers which URLs they may request. It cannot keep a page out of search, because Google can still index a disallowed URL when other pages link to it. To keep a page out of results, allow crawling and add noindex, or put the page behind a password.

For robots.txt, check that:

• Every host has its own file. A robots.txt on www.example.com does not cover docs.example.com, the HTTP version of the site or another port.
• The file returns 200, or 404 if you have none. A server error is worse than no file, because Google stops crawling the site for 12 hours and then works from the last good copy for up to 30 days.
• No leftover Disallow: / from a staging site made it into production.
• The file stays under 500 KiB, the limit after which Google ignores the rest.
• Paths match real URLs letter for letter. Rule values are case-sensitive, so a rule for /Blog/ does not block /blog/.
• The CSS, JavaScript and API paths that pages need for rendering are open.

For XML sitemaps, check that:

• Each sitemap holds at most 50,000 URLs and stays under 50MB uncompressed.
• Every URL is absolute, returns 200 and is the canonical version. Redirects and noindexed pages in a sitemap contradict your other signals.
• lastmod changes only when the content changes, since Google uses it only when it is consistently accurate. Google ignores priority and changefreq.
• The sitemap is submitted in Search Console or listed in robots.txt with a Sitemap: line.

Then compare the sitemap with the crawl. A sitemap URL the crawler never reached has no internal links pointing to it.

3. Status codes and redirects

Sort the crawl export by status code and read each group.

• 4xx. Google drops these URLs from the index over time. A 404 is correct for a page you removed on purpose, and any internal links to it should be updated.
• Soft 404. The page says "not found" or shows an empty template but returns 200. Return a real 404 or 410, or give the page useful content.
• 403. Googlebot never sends credentials, so a 403 sent to it keeps the page out of the index.
• 5xx and 429. Google slows its crawl when it receives these, and indexed URLs that keep failing are dropped in the end. A pattern on one template points to the server or the code.
• Redirect type. Permanent moves use 301 or 308. Google treats a 302 or 307 as only a weak signal that the target should replace the old URL.
• Chains and loops. Point each redirect straight at the final URL. Google follows up to 10 hops but advises keeping chains short, ideally no more than 3, and Search Console lists loops and overlong chains under Redirect error.

Google recommends server-side redirects and advises JavaScript redirects only as a last resort. After a recent move, crawl the old URL list and confirm each address lands on the right page in one hop. Keep those redirects for at least a year, as Google advises. A full move needs its own plan, which our website migration SEO checklist covers.

4. Canonicals and duplicate URLs

Most sites serve some pages at more than one address, such as HTTP and HTTPS versions or URLs with a tracking parameter. Google groups these duplicates and picks one canonical. When your signals disagree, Google may pick a URL you did not intend.

• Each indexable page has a self-referencing canonical with an absolute URL.
• The canonical tag, the sitemap entry and any redirect all name the same URL. Google warns against declaring different canonicals through different methods.
• The canonical target returns 200, is indexable and does not redirect.
• No canonical points at a page with different content, because Google will not choose a canonical that is not similar to the page.
• Filter, sort and tracking parameters canonicalize to the clean URL or stay out of internal links.
• robots.txt is never used for duplicates. Google cannot read a canonical tag on a page it may not crawl.

Where Google chose a different canonical, look for signals pointing the other way. Google lists redirects and canonical tags as strong signals and sitemap inclusion as a weak one.

5. Site architecture and internal links

Google can reliably follow a link only when it is an <a> element with an href attribute. A menu built from <span> elements or onclick handlers works for users, while crawlers may never find the pages behind it.

• Important pages can be reached through normal links from the homepage or main navigation, and not only through site search or filters.
• No orphan pages exist among the URLs you care about. The sitemap comparison in group 2 finds them.
• Commercial pages sit a few clicks from the homepage. The crawler's depth column shows the distance.
• Internal links point straight at final canonical URLs. A link to a redirect adds a hop for every visitor and crawler.
• URLs use readable words and standard ?key=value parameters. Google Search generally ignores content that changes with a #fragment.
• Faceted navigation does not create a crawlable link for every filter combination. On a large catalog those combinations can produce a great many near-duplicate URLs.

6. Titles, meta descriptions, headings and hreflang

The fix for these items is usually one template change.

• Every page has a <title>, and titles differ between pages. Google advises against boilerplate titles that change by one word. There is no length limit, though Google shortens long title links to fit the screen.
• Key templates have a meta description that describes the page. Google builds most snippets from page content, so a missing description on a low-value archive page is a minor finding.
• Each page has one main heading that names its topic. Watch for templates that print the site name as the H1 on every page.

Sites in more than one language add hreflang, which Google accepts in the HTML, in HTTP headers or in the sitemap. Check that:

• Each language version lists itself and every other version.
• Every link is returned. If page A names page B and B does not name A, Google ignores the pair.
• URLs are fully qualified, and language codes follow ISO 639-1, with an optional region as in en-US.
• An x-default entry covers visitors whose language you do not serve.

7. Rendering and JavaScript

Google crawls a page, queues it for rendering and indexes the rendered result. The page can sit in that queue for a few seconds or longer, and some other crawlers do not run JavaScript at all.

The core test compares two crawls of the same site, one on raw HTML and one with JavaScript rendering on. Compare them template by template, starting with titles and canonicals. Then check the body text and internal links. Anything that appears only in the rendered crawl depends on JavaScript.

• Main content and links appear in the HTML that Google renders. In URL Inspection, run Live Test and open View tested page to see Google's screenshot and HTML.
• The original HTML of a page you want indexed never contains noindex. Google may skip rendering once it sees noindex, so a script that removes it later may never run.
• Any canonical set by JavaScript matches the one in the original HTML.
• A single-page app reports missing pages properly. A missing product should redirect to a URL that returns 404, or add noindex, so it does not become a soft 404.
• Routes use the History API with real paths in place of #/ fragments.

Google still recommends server-side rendering or pre-rendering, because it makes pages faster and not every bot runs JavaScript. A move to it is an engineering project, so the audit names the affected templates and lets the team size the work.

8. Mobile-first indexing

Responsive layouts sometimes hide sections, tables or links on small screens to save space. Google crawls with its smartphone agent and uses the mobile version of a page for indexing and ranking. When the mobile layout drops content, the smaller page is the one that gets indexed.

On a sample of each template, compare mobile and desktop for:

• The same main content and headings.
• The same robots meta tags. A noindex that exists only on mobile can stop Google from indexing the page.
• The same structured data and image alt text.
• Main content that loads without a tap, swipe or typed input. Google does not load content that needs user action to appear.

9. Core Web Vitals and page speed

Field data decides what to fix, and lab data finds the cause. Google's thresholds for a good experience are:

• Largest Contentful Paint (LCP), for loading: 2.5 seconds or less.
• Interaction to Next Paint (INP), for response to input: 200 milliseconds or less.
• Cumulative Layout Shift (CLS), for visual stability: 0.1 or less.

Each metric is read at the 75th percentile of page loads, separately for mobile and desktop. A page passes when all three meet the target.

Open the Core Web Vitals report in Search Console first. It groups similar URLs and gives each group the status of its worst metric. Only indexed URLs with enough data appear, so a missing template may simply lack traffic. For each failing group, run a sample URL through PageSpeed Insights. Its top section shows field data from real Chrome users over the last 28 days. The Lighthouse lab test below it is where you look for causes. Pages with little traffic may show data for the whole origin instead, so note which one you are reading.

Google uses Core Web Vitals in its ranking systems. Its page experience guide also says that chasing a perfect score only for SEO reasons "may not be the best use of your time".

10. Structured data

Valid markup only helps an indexed page, by making it eligible for a search feature such as a product or review result.

• Markup uses JSON-LD where possible, as Google recommends for most sites.
• Every key template passes the Rich Results Test, and errors in Search Console enhancement reports are fixed once, in the template.
• The markup describes content that readers can see. Marking up hidden content can lead to a manual action, which removes rich result eligibility.
• No ticket promises FAQ rich results. Google stopped showing them from 7 May 2026.

Google does not guarantee a rich result even when the test passes. Record eligibility in the audit and leave display out of the success criteria.

11. HTTPS and security

The HTTPS report in Search Console counts your indexed HTTP and HTTPS URLs, and ideally every indexed URL is HTTPS. Three checks below match the report's reasons for a failed HTTPS version, and the mixed-content check comes from browser behavior:

• The certificate is valid on every host. An invalid certificate usually affects the whole site.
• Each HTTP URL redirects permanently to HTTPS in one hop, and no HTTPS URL redirects back.
• Canonical tags and sitemaps use the HTTPS version.
• Pages load no images, scripts or stylesheets over HTTP. Most browsers now block this mixed content, which can break parts of the page.

12. Server logs, for large sites

Server logs show which URLs crawlers actually requested. Google calls its Crawl Stats report a tool for advanced users and says sites under a thousand pages should not need it. Its crawl budget guide targets far larger sites: a million or more pages that change weekly, or ten thousand or more that change daily. Google calls those figures a rough estimate. A site far below them can skip this group.

On a large site:

• Start with the Crawl Stats report. Host status shows failures in robots.txt fetching, DNS resolution and server connection.
• Verify that requests claiming to be Googlebot are real. Run a reverse DNS lookup on the IP and check that the host ends in googlebot.com, google.com or googleusercontent.com. Then run a forward lookup on that name and confirm it returns the same IP.
• Group crawler hits by template. Many hits on parameter URLs, old redirects or soft 404s mean crawl time is going to pages you do not want.

How to prioritize the findings

Taking findings in the order the crawler prints them puts cosmetic warnings next to faults that cost you indexed pages. The four scoring points and five bands below are our judgment and have not been measured, so adjust them to your own evidence:

• Indexing impact comes first. A finding that keeps important pages out of the index outranks everything else.
• Reach is next. A template fault affects every page built from that template.
• Confidence counts too. A fault confirmed in URL Inspection or the HTML outranks an unchecked crawler warning.
• Effort and ownership complete the score, meaning the size of the fix and whether the code owner has time for it.

Those points sort findings into five bands:

• First: important pages blocked by robots.txt, set to noindex, returning errors or redirected to the wrong place. A leftover staging rule or an invalid certificate belongs here, since each affects a whole host.
• Second: template faults that send mixed signals, such as conflicting canonicals, content that exists only after JavaScript runs, thin mobile pages and soft 404s.
• Third: crawl waste and structure, including facet URLs, orphan pages, redirect chains and sitemap errors.
• Fourth: Core Web Vitals on failing URL groups that carry traffic, and structured data errors.
• Last: crawler warnings on pages nobody searches for, some of which never need a fix.

Low effort can move an item up within its band, so a one-line robots.txt correction should not wait behind a rendering rebuild. If a migration is planned, check its URL map and redirects before anything else on this list.

What the finished audit report should contain

A developer should be able to pick up each finding without asking for a meeting first. The report needs:

• A one-page summary of the top findings in priority order.
• The scope, meaning hosts, templates, sample URLs and the date of every data export.
• For each finding, the fault, the evidence (a status code, report row, crawl column or screenshot), the affected template and one example URL.
• The priority with its reason, an owner and a test that proves the fix. A good test names the tool and the expected result, for example a URL Inspection live test showing the self-referencing canonical on three sample product URLs.
• The checks that passed, so the next audit does not repeat them.

Many SEO tools keep a stored copy of what a data provider returned, and that copy ages. The keyword and competitor research workspace we built for a private client labels each cached report with the time it was saved. The provider's own metrics may be older still.

Checking that the fixes worked

Record the date each fix goes live. Run Live Test in URL Inspection on a few sample URLs, then use Validate fix in the Page indexing report. Validation stops as soon as Google finds one URL that still has the problem, so fix every instance before you start it.

After that, compare indexing and impressions for the affected URL group before and after the fix date. Rank reports need more care, because a position only compares with one measured under the same conditions. The rank tracker we built for a private client stores the country, the device and any location with every position. It records a failed provider check as a failed measurement and retries it. The history therefore does not log that failure as a ranking loss. Before you report a drop after a fix, confirm that the check succeeded and that its country, device and location match the earlier one. The tracker is internal software and shows no client ranking result. Our SaaS guide explains how to tell whether the fixes worked in more depth.

No fixed timeline links a technical fix to a ranking change. Our guide on how long SEO takes covers the factors that decide it.

When to run the audit yourself and when to get help

A team with a developer who can read the templates can work through most of this checklist. Trouble tends to start once the report is delivered, because the SEO lead owns the findings while engineering owns the code.

Our technical SEO audit services are built for that gap. We audit by template and by architecture. Each finding becomes a developer ticket that names the affected templates and expected impact, plus the people who make and check the change. After the fixes ship, we recheck representative URLs against the recorded fix date. If your team cannot get to the tickets, our engineers ship the fixes themselves. We do not promise rankings or traffic.

Faults like these return when new templates ship without the same checks. Our guide to technical SEO essentials for developer teams covers the checks to build into each release.

FAQ

What is the difference between a technical SEO checklist and an SEO audit checklist?

A technical SEO checklist covers how search engines crawl, render and index a site. A full SEO audit checklist usually adds content quality, keyword targeting and backlinks.

How often should you run a technical SEO audit?

We suggest a full audit before and after any migration, redesign or platform change, and at least once a year otherwise. Between audits, a monthly look at the Page indexing, HTTPS and Core Web Vitals reports shows new problems early. This cadence is our recommendation and does not come from Google.

Does a small site need every item on this checklist?

A small site can skip several groups, including the reports that Google says small sites do not need (see groups 1 and 12). On a small site we would cover groups 1 to 4 fully and then move to groups 6, 8 and 11.

Will fixing technical issues improve rankings?

Fixes remove barriers to crawling and indexing. They cannot guarantee a ranking or traffic change. Where a page ranks still depends on its relevance and on the pages it competes with.